OSLC Lifecycle Integration for Project Mgmt of Contracted Delivery (PROMCODE) TC

Fw: Proposed solution framework for handling OSLC URIs/identifiers on open-services.net

  • 1.  Fw: Proposed solution framework for handling OSLC URIs/identifiers on open-services.net

    Posted 12-16-2014 18:09
    FYI, I was hoping someone from this TC had received this.  Since I'm not sure of that, I'm forwarding it directly. Thanks, 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