[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-9) Bootstrapping discovery
[ https://issues.oasis-open.org/browse/OSLCCORE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59672#comment-59672 ]
Martin Pain commented on OSLCCORE-9:
-------------------------------------
IIRC, in OSLC 2.0 there's no guarantee that all the summary information will be in one document. You could have a catalog that provides links to service providers but does not inline any details about them (i.e. does not itself provide any details about their capabilities). The service provider resources could then, in the same way, link to service resources without inlining any details about them. So the clients would have to navigate a tree of depth 3 to get any capabilities.
So, in addition to the things not included in v3 that you've already addressed Jim, I see the differences as:
1) OSLC v2 provides a way to inline it all in one document if servers choose to do so, v3 does not (as v2 had it in the RDF, in v3 its in HTTP headers - is that true across the board? if there's anything in OSLCv3/LDPC capability discovery that's in the RDF then it can be inlined in parent containers)
2) OSLC v2 has an implied suggested tree depth of 3 (although apparently catalogs can provide links to other catalogs, allowing an arbitrary depth), if in v3 we're nesting containers in containers there is no guidance on what sort of structure of depth to use, so there is less to guide clients' expectations.
It should be simple to convert any Link headers into RDF triples (although whether the meaning is the same is debatable), which would be one way of inlining the capability information in one document. However, I'm not aware of a nice way to do things like the Allow, Accept, Accept-Post headers etc (other than using http://www.w3.org/2011/http#HeaderElement, but I don't consider that a 'nice' way).
Re-using the v2 approach for servers who want to expose the information in a single document certainly helps with compatibility. It feels like missing an opportunity to leave some baggage behind, but as long as it's a MAY for clients to understand it (the HTTP header means of discovery being the MUST for servers to implement) then that's probably the right balance.
> Bootstrapping discovery
> -----------------------
>
> Key: OSLCCORE-9
> URL: https://issues.oasis-open.org/browse/OSLCCORE-9
> Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
> Issue Type: Task
> Reporter: Martin Pain
> Assignee: James Amsden
>
> See https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html
> See also a draft from Mark Nottingham about HTTP home documents: http://tools.ietf.org/html/draft-nottingham-json-home-03 (I haven't read it yet)
--
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]