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: Re: [oslc-core] OSLC Core 3.0 overview is ready for TC review

I've just looked at the latest diff, not done a top-to-bottom read. Mostly editorial issues, with some comments on the changed content too:
  1. There's now an empty <section> element with ID "conformance". Is that something that we need to flesh out?
  2. In "Version Compatibility": "There is a significant number of existing OSLC domains" should that be "are"? Perhaps "There exist a significant number of OSLC domains" would be better, or "A significant number of OSLC domains exist" or "have been defined". Very minor point, but it made me trip when reading it. "A significant number of OSLC domains, client implementations and server implementations already exist".
  3. "it's compatibility needs" -> "its compatibility needs"
  4. "there is no need for OSLC Core 3.0 to require servers or clients to utilize an OSLC-Core-Version header with a value of 3.0". This sentence doesn't provide the context for understanding why we're mentioning the OSLC-Core-Version header. Would a link to the definition of the header in 2.0 help to set the picture? Even if it's something the implementors don't need to know about, at least they can understand what it is that we're saying that they don't need to use, and why we have to say that. e.g. the link could say "as previously used in the OSLC 2.0 compatibility guidance". I see we already have the link later, but it doesn't explicitly give the context for the OSLC-Core-Version header.
  5. Should we explicitly allow OSLC-Core-Version: 3.0? I suggest not. Servers that support pre-Core (1.0) and 2.0 need to receive OSLC-Core-Version: 2.0 in order to return a 2.0 representation. It doesn't look like we ever say that clients SHOULD provide that header, (it says "We expect clients that target the Core to send this HTTP header.").
    3.0 clients with 1.0 & 2.0 servers: So if you have a server that supports 1.0 and 2.0 (so requires the header in requests from a 2.0 client), and the client is upgraded to support OSLC 3.0, then it needs to still send OSLC-Core-Version: 2.0, otherwise that server will fall back to the 1.0 resources, which are not compatible. If we care about new 3.0-only clients being compatible with 2.0 serves, then either we should "expect that" clients send, or clients MUST send, "OSLC-Core-Version: 2.0" (despite being 3.0 clients).
    2.0 clients with 3.0 servers: However I think we said that the compatibility requirement is that 2.0 clients work with 3.0-only servers. In which case 3.0 clients only need to send the "OSLC-Core-Version: 2.0" header if they need to be compatible with older servers (we could still make it a SHOULD). 3.0-only servers can ignore the header. If a server initially supported 2.0 but was then upgraded to 3.0, I suggest we explicitly say that on receiving an "OSLC-Core-Version: 2.0" header it returns the 3.0 representation. This is counter-intuitive, but we have no need to request 2.0 representations from a 3.0 server as they are 100% backwards compatible. (At least in core - other domains can define their own ways of specifying version if they need it).
    I don't think the existing statement saying to support compatibility with 1.0 refer to the 2.0 spec is enough, as clients not wanting to be compatible with 1.0 can break compatibility with 2.0 servers that also implement 1.0 if the client doesn't send "OSLC-Core-Version: 2.0".
  6. " that is compatible with 2.0 The response may include" - missing full stop after "2.0".

Kind regards,

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

Phone: +44 (0)1962 815317 | Tie-Line: 37245317
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 

IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

From:        "Jim Amsden" <jamsden@us.ibm.com>
To:        "OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date:        22/07/2015 22:09
Subject:        [oslc-core] OSLC Core 3.0 overview is ready for TC review
Sent by:        <oslc-core@lists.oasis-open.org>

See https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/jra-editing/specs/oslc-core.html. This has the initial set of changes required to address OSLC2 compatibility.

Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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