OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (OSLCCORE-5) What are the OSLC 2.0 / 3.0 Compatibility Requirements


    [ https://issues.oasis-open.org/browse/OSLCCORE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59689#comment-59689 ] 

Nick Crossley commented on OSLCCORE-5:
--------------------------------------

The vocabulary and shapes documents are independent - neither is derived from the other. ReSpec forms the human-readable tables in the HTML specs from the shapes, and forms a human-readable HTML representation of the vocabulary, as two separate transforms.

Although there is some overlap between the shapes and the vocabulary (particularly in the names and descriptions of the RDF terms), there are some key differences that make it difficult to derive one from the other. In simple cases, the shapes are richer, and one could generate a vocabulary from a shape with the addition of a small amount of extra info about the vocabulary itself.

However, a vocabulary term could be used in two or more different contexts, where the description of the term is somewhat generic, while the shape describes a specific property that may appear in one or more classes - that is, the shape dcterms:description of a property may be more specific to a particular context than the rdfs:comment on the vocabulary term.

Finally, there are some additional properties that one can put on RDF terms in the vocabulary (vs:term_status, the inverse label and traceability properties defined in  http://open-services.net/wiki/core/Vocabulary-Annotation-Vocabulary/, etc.)

One way to look at it is that the vocabulary document defines the meaning of each individual term (the vocabulary), while the shapes defines the way things are put together (the grammar).

But your conclusion is still correct - the shapes must be upward compatible.  It is incomplete - the vocabulary must also be upward compatible.


> What are the OSLC 2.0 / 3.0 Compatibility Requirements
> ------------------------------------------------------
>
>                 Key: OSLCCORE-5
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-5
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> Are clients and servers expected to reflectively support both versions with no compatibility implied between them? This appears to be the current compatibility approach and guidance.
> What is the recommendation for OSLC 2.0 capabilities not yet included in OSLC 3.0 - avoid them, implement them on a 3.0 server? Do we even know if that’s possible? Use a 2.0/3.0 hybrid server? Will vendors be willing to implement that? Is it practical?
> Given a recommendation, what are the possible incompatibilities that might need to be discovered and addressed in the current OSLC 3.0 specifications? 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]