Re: [oslc-core] Proposed solution framework for handling OSLC URIs/identifiers on open-services.net -- FEEDBACK by 9/25

[Martin P Pain <martinpain@uk.ibm.com>]

A) Evolution of existing documents

> 5. IBM (with the OSLC Community) commits to an
arrangement for 
> server configuration under which HTTP scheme URIs that identify 
> namespace names, properties, classes **for OASIS Work Products** 
> ...

This doesn't explicitly address
evolution of existing documents (e.g. the OSLC Core vocab RDF file). I
read it as implying that the evolved documents will be treated (by OASIS)
as being new documents, but having the URI of the old one. The TC will
consider it as an evolution of the existing file, but physically stored
in a different location/service (but still accessible via the same URI).
Perhaps we ought to say/agree that explicitly.



B) Secondly, and much more minor:
incorrect implication of use of DNS

> ...
> will resolve (DNS) to resources canonically stored on docs.oasis-open.org
> (OASIS Library)  [e.g., via HTTP 300-range redirects, or via
reverse
> proxy...], as expected for Approved Work Products

Stating "(DNS)" suggests a
technology choice, which is contradicted by the next 2 lines and by:

> We acknowledge that a few technical details
> (e.g., reverse proxy versus redirects) need to be worked out, as 
> implementation details.

Which is presumably because of:

> The wording above is just my personal paraphrase,
and if anything is
> unclear, we can clarify or adjust.  It's not meant to be legal
> language.

So I suggest this is adjusted by the
removal of "(DNS)".



Other than that it all looks good to
me. Although I suggest we tie down which approach will be used for the
solution to point 5 ASAP, but by the sounds of it that's down to the choice
of open-services.net, not OASIS.

Martin

<oslc-core@lists.oasis-open.org> wrote on 17/09/2014
17:53:14:

> From: Steve K Speicher <sspeiche@us.ibm.com>
> To: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 17/09/2014 17:53
> Subject: [oslc-core] Proposed solution framework
for handling OSLC 
> URIs/identifiers on open-services.net -- FEEDBACK by 9/25
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> OASIS OSLC Core TC Members, 
> 
> I'm forwarding the currently proposed solution framework to gain 
> feedback.  We have been tracking and discussing this item for
some 
> item and happy to see the progress. 
> 
> I'd like to: 
>   a) Review this at tomorrow's TC meeting (September 18, 2014)
>   b) Allow for some fixed time to receive some review feedback
(by 
> September 25, 2014). 
> 
> Regards,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> http://open-services.net
> 
> <robincover@gmail.com> wrote on 09/16/2014 08:27:52 PM: 
> 
> OASIS Staff reached a milestone in the discussion [2a] about handling
of the 
> open-services.net URIs, and a summary [1a] of the proposed solution
framework.
> 
> I provide the text for both below, for your review, but I hope this
> presents no surprises, as we have been leaning in the same general
> direction for a while.  Please let me know if anything presented
> here seems problematic.  We acknowledge that a few technical
details
> (e.g., reverse proxy versus redirects) need to be worked out, as 
> implementation details.
> 
> Principal conclusions, as proposed:
> 
> 1. OASIS TCs continue to use domain "open-services.net"
as base for 
> NS URIs and associated identifiers
> 
> 2. IBM (with OSLC Community) continues to register and own the "
> open-services.net" Internet domain
> 
> 3. IBM (with OSLC Community) provides written statement to OASIS 
> expressing agreement with this longer-term disposition: agreement
to
> grant OASIS (or its natural successor) the first right of refusal
> for ownership of the "open-services.net" Internet domain
in the 
> event that the OSLC Community is no longer able or willing to 
> maintain support for the domain and the solution broadly envisioned
> in this proposed solution framework
> 
> 4. IBM (with the OSLC Community) owns/controls the hardware/machine
> that hosts the "open-services.net" Web server, and continues
to 
> operate/manage the Web server with respect to the "open-services.net
> " HTTP scheme URIs that identify namespace names, properties,
> classes, and similar names, sub http://open-services.net/ns/*
(as 
> may be relevant to OASIS specs), and for other OSLC Community 
> resources/URIs (wiki, blog, etc)
> 
> 5. IBM (with the OSLC Community) commits to an arrangement for 
> server configuration under which HTTP scheme URIs that identify 
> namespace names, properties, classes **for OASIS Work Products** 
> will resolve (DNS) to resources canonically stored on docs.oasis-open.org
> (OASIS Library)  [e.g., via HTTP 300-range redirects, or via
reverse
> proxy...], as expected for Approved Work Products
> 
> 6. The OASIS OSLC TC Chairs and relevant parties in the OSLC 
> Community acknowledge the OASIS expectation that the OSLC TCs' Work
> Products as represented in the OASIS Library should conform to all
> other requirements of OASIS policy (TC Process, Naming Directives),
> other than the directives governing Namespace Identifiers and 
> Namespace Documents, for which variance has been given, per #1 above
[ 
> http://docs.oasis-open.org/specGuidelines/ndr/
> namingDirectives.html#xml-namespaces ] 
> 
> The wording above is just my personal paraphrase, and if anything
is
> unclear, we can clarify or adjust.  It's not meant to be legal
> language.  The key takeaway is that the OASIS TCs can continue
to 
> work just about as they have been with respect to namespace URIs,
> including e.g., use of the "open-services.net" substring
for the new
> PROMCODE TC spec(s), and similarly.
> 
> Please let me know if this all seems reasonable as a way forward,
> even as new discussions take place on the matter of composition of
> (multi-part) Work Products and associated URIs for assets in the 
> OASI Library (docs.oasis-open.org).
> 
> Thanks for your patience in this discussion process.
> 
> - Robin 
> 
> [1a]   ================ Exec Summary
> 
> ==========
> Summary
> ==========
> 
> In conversation with OASIS OSLC TC principals, OASIS Staff is 
> proposing a framework solution for ownership and management of OSLC-
> spec-related URIs, whereby the legacy naming patterns (using open-services.net
> ) are maintained, but all canonical resources that make up OASIS 
> Work Products are stored in the OASIS Library (docs.oasis-open.org).
> The OSLC Community would continue to own and operate the Web server
> associated with "open-services.net", and support server
> configurations to provide HTTP redirects (using content negotiation)
> so that the relevant OASIS resources are fetched and delivered from
> the OASIS Library.
> 
> =========
> Details
> =========
> 
> As OASIS OSLC Member Section TCs have begun creating new 
> specifications and transitioning earlier versions of the OSLC 
> Community specifications to OASIS, questions have arisen [1] about
> allocation and management of new and legacy URIs which identify 
> namespace names, classes, properties, etc.
> 
> The expectation for new or newly constituted OASIS specifications
is
> that all such HTTP scheme URIs will conform to the OASIS Naming 
> Directives [2], and be based upon the http://docs.oasis-open.org
> Internet domain.
> 
> The OSLC developer community has expressed a strong opinion that the
> legacy URIs (based upon http://open-services.net/ns/
) not be 
> changed, as such change would disrupt current implementations; and
> further, that newly minted URIs/names should also follow the legacy
> naming patterns established for OSLC Community specs [3],
> 
> Under these circumstances, Staff wishes to support a solution 
> framework that grants a variance against the Naming Directives by
> allowing use of the domain open-services.net as a base for URIs, 
> while requiring that the canonical versions of all OASIS related 
> Work Product assets be stored on the OASIS server.  Experts in
the 
> OSLC Community would continue to provide server support for http://
> open-services.net/ such that applicable HTTP scheme URIs would 
> dereference (via HTTP redirects and transparent content negotiation)
> to physical resources in the OASIS Library.
> 
> In support of the OASIS commitment to longevity and permanence of
> immutable Work Product resources, Staff requests that the OSLC 
> Community agree to grant OASIS first right of refusal for ownership
of the "
> open-services.net" Internet domain in the event that the OSLC
> Community is no longer able or willing to maintain support for the
> solution described above.
> 
> 
> [1] "Vocab Stable URI Notes"
> http://wiki.oasis-open.org/oslc-core/VocabStableURINotes
> 
> [2] OASIS Naming Directives
> http://docs.oasis-open.org/specGuidelines/ndr/
> namingDirectives.html#xml-namespaces
> 
> [3] OSLC Community naming rules
> http://open-services.net/wiki/core/OSLC-Core-URI-Naming-Guidance/
> http://open-services.net/wiki/core/Vocabulary-index/
> http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations
> http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
> http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks
> 
> ==================================================
> 
> [2a]   Text of proposal as discussed by Staff  (Robin, Chet,
Scott)
> 
> OSLCC = OSLC Community
> 
> 1. Should we ask IBM/OSLCC to reconsider their verdict on the 
> namespace URI domain for OASIS-OSLC-specifications, and ask that 
> they adhere to the OASIS policy (Naming Directives) for namespace
> URIs and related identifiers?
> - Tentative: probably not
> - Decision SCR 2014-09-09: no; domain to be open-services.net
> 
> 2. Should we (without fanfare or announcement) declare open-services.net/[TBD]
> a "designated facility" for ownership/control of the namespace
URIs 
> [ per TC Process: https://www.oasis-open.org/policies-guidelines/tc-
> process#visibility "located only on facilities designated by
OASIS" ]
> - Tentative: yes
> - Decision SCR 2014-09-09: yes (to arguably comply with TC Process),
> but details TBD
> 
> 3. Who should own the Internet domain "open-services.net"?
> - Tentative: IBM/OSLCC
> - Decision SCR 2014-09-09: IBM/OSLCC
> 
> 4. Who should own/control the hardware/machine that hosts the "open-
> services.net" Web server?
> - Tentative: probably depends upon #3, but likely IBM/OSLCC
> - Decision SCR 2014-09-09: IBM/OSLCC
> 
> 5. Who should operate/manage the Web server with respect to the "
> open-services.net" HTTP scheme URIs that identify namespace names,
> properties, classes, and similar names, sub http://open-services.net/ns/*
?
> - Tentative: probably depends upon #3-#4, but likely IBM/OSLCC
> - Decision SCR 2014-09-09: IBM/OSLCC
> 
> 6. Should OASIS commit to an arrangement under which OASIS is 
> responsible for content/serverConfiguration [i] for *some* (but not
> all) directory/file resources hosted on "open-services.net/*"
 e.g.,
> for RDF schema files or vocabularies relating to OASIS-OSLC Work 
> Products, [ii] but NOT for all resources, e.g., NOT the OSLCC Wiki
> files, non-OASIS-OSLC-specifictions, etc?
> - Tentative: probably depends upon #3-#4-#5, but provisionally: no
> - Decision SCR 2014-09-09: no; rather: pursue current plan to have
> ALL OASIS-Work-Product-related-resources on docs.oasis-open.org, for
> approved Work Products
> 
> 7. Should OASIS ask for an arrangement/agreement under which HTTP
> scheme URIs that identify namespace names, properties, classes **for
> OASIS Work Products** will resolve (DNS) to resources canonically
stored on 
> docs.oasis-open.org (OASIS Library)?
> - Tentative: yes, unless technical impediments prevent server 
> configuration on "open-services.net" from supporting such
> resolution/dereferencing
> - Decision SCR 2014-09-09: yes, (thus) pursuing the tentative 
> solution already in process
> 
> 8. Should OASIS clarify with IBM/OSLCC -- now -- that we expect the
> OSLC TCs' Work Products as represented in the OASIS Library to 
> conform to all other requirements of OASIS policy (TC Process, 
> Naming Directives), other than the directives governing Namespace
> Identifiers and Namespace Documents, for which variance has been given
[ 
> http://docs.oasis-open.org/specGuidelines/ndr/
> namingDirectives.html#xml-namespaces ]
> - Tentative: yes
> - Decision SCR 2014-09-09: yes, details TBD
> 
> 
> 
> 
> 
> -- 
> Robin Cover
> WWW:  http://xml.coverpages.org
> Tel: +1 (972) 296-1783 
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