NO ACTION - Read over Appendix B section "Specifying the shape of a query result" and with the addition of rdfs:member to common properties, I think we are covered.
"true if the property is read-only. If not set, or false, the property is writable."
"Providers SHOULD declare a property read-only when changes to the value of that property will not be accepted on PUT. Consumers should note that the converse does not apply: providers MAY reject a change to the value of a writable property."
Defer:
Give oslc:readOnly is of type xsd:boolean, we adopt the lexical space defined by XSD (true, false, 0, 1).
"For properties with a resource value-type, Providers MAY also specify the range of possible resource classes allowed, each specified by URI. The default range is http://open-services.net/ns/core#Any."
Questions about Atom representations of query results
RESPONSE: clarify guidance as follows "OSLC domains should specify whether the content element contains unconstrained RDF/XML or the abbreviated form of RDF/XML that we present in this guidance. Unconstrained RDF/XML should be indicated with content type "application/rdf+xml" and the abbreviated form should be indicated with "application/xml."
AI Everybody: review Arthur's guidelines
RDF/HTML content for our namespace and property URIs
Clarifications sought for Resource Shape oslc:readOnly
Steve S: could also be POST, not just PUT
AI Dave J to clarify
Issues with Resource Shape allowed values
Dave J: this looks OK, the most obvious interpretation is the correct one
Ian G: then let's clarify
Dave J: if this is not a breaking change, then let's make it
Steve S: not a breaking change
Ian G: not a breaking change
AI Dave J to clarify that union is the correct interpretation
Clarifications sought for oslc:range
AI Dave J to clarify using Ian's language
Scott B: note that Steve S and I have an active TODO item to review specs an ensure they are using the most appropriate range, which is usually going to be 'any'.
Questions about Atom representations of query results
Scott B: we should make it clear that guidance is for XML, not RDF/XML
Dave J: yes, we do not make this clear in the guidance and also in some places in the Core spec itself
Steve S: the guidance is valid an useful for those who need to generate RDF/XML or understand how to go from RDF data model to a representation.
Dave J: true, but the guidance is for generating RDF/XML and not for parsing it
AI Dave J: review guidance, review core - make changes to make the RDF/XML and XML distinction clear
AI Dave J: add link annotation to representation guidance for XML
AI Everybody: review Arthur's guidelines
AI Steve S: will do the write up for Core
Scott B: we have EM and CM and Core on the way, Ian: when will we see RM?
Ian G: should get to it in the near future
Can we finalize?
Steve S: we are close in CM, 3 implementations completing now
Ian G: only aware of one provider implementation ongoing, no shape or query implementations yet
Scott B: we're putting together proposal for open sourcing some OSLC test suites, JUnit-based tests that test a provider implementation. We have questions about the licenses and the location. We like permissive licenses, such as Apache. We like public hosting sites such as Google Code and SourceForge? . We'd like your feedback.
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Contributions are governed by our Terms of Use Ideas, requests, problems regarding this site? Send feedback