This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

OSLC Core Meeting October 13, 2010

Last week's meeting

Meeting logistics

See the OslcCoreMeetings for more information, more dial-in numbers and on-line meeting information.

  • Conference Access
    • Toll free: 1-866-423-8350
    • Toll: 1-719-387-8273
  • Participant passcode: 558663

Agenda

  • Clarifications sought for Resource Shape oslc:readOnly
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000600.html
    • RESPONSE:
      • Accept:
        • "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).

  • Questions about Atom representations of query results
    • http://open-services.net/pipermail/oslc-core_open-services.net/2010-October/000602.html
    • 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."

Minutes

Attendees and notes from the meeting

Attendees

Topics discussed

TBD

  • AI Dave J: add rdfs:member to common properties

  • AI Dave J: propose clarification for rdfs:member

  • 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.
    • Jim C: I prefer SourceForge?
    • Dave J: I prefer Google Code
    • Mike L: either is fine with me, access to code is the most important
    • Dave J: another option, which may be too much overhead, is to incubate an Apache project
Topic revision: r4 - 22 Oct 2010 - 18:32:05 - DaveJohnson
 
This site is powered by the TWiki collaboration platform 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