[oslc-core] How will Resource Shapes be provided?

[Nick Crossley]

Presumably I misunderstood, because I always thought the provider-specific 
properties would be described in the shape - that is, your choice 2(b).  I 
do not consider this a new feature added during convergence, since we have 
always said that providers can add extra properties, and we have said that 
resource shapes are there (amongst other things) to help during query - so 
surely providers should put their added properties into the shape.  I 
fully agree such properties must use a different name space.

For this reason, I do not see a good argument for putting resource shapes 
on open-services.net, since such shapes would not be the ones linked from 
any real resources.

Nick.



From:   Dave <snoopdave at gmail.com>
To:     oslc-core <oslc-core at open-services.net>
Date:   06/16/2010 12:47 PM
Subject:        [oslc-core] How will Resource Shapes be provided?
Sent by:        oslc-core-bounces at open-services.net



We expect that OSLC domain specifications will specify Resource Shapes
for some resources. How will we provide these shapes and can providers
extend them? Consider these two question:

1) Should we make OSLC defined shapes available at open-services.net
or do we expect that providers will each provide these shapes as part
of their implementation? My opinion: we should do both. Make shapes
available on open-services.net and recommend that allow providers to
provide them as well.

2) If we allow implementations to provide the specified shapes, what
are the requirements? What changes are implementations allowed to
make? Can they add new "custom" properties? I have two opinions on
this one:
a) Implementation must provide the OSLC Defined Resource shapes
verbatim with no changes and no additional properties. Resource Shape
Extensibility is a new feature not in the spec and we shouldn't add
new features during convergence.
b) Implementations must not remove or add any properties to an OSLC
defined resource shape, but may add new custom properties. To prevent
conflicts, for custom properties, implementations should define
entirely new properties in an entirely implementation-specific
namespace.

Thanks,
- Dave

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100616/d548396c/attachment-0003.html>