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] Proposed solution framework for handling OSLC URIs/identifiers on open-services.net -- FEEDBACK by 9/25


Did we ever get the agreement to resolve (ideally via reverse proxy) the OASIS documents from open-services.net URLs? The last two emails I can find on the subject are below, (plus my response here: https://lists.oasis-open.org/archives/oslc-core/201409/msg00028.html).

This was the proposed solution, and the TC appears to accept it here (without a vote): https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.09.18#Minutes
However, I'm not sure it was every formally agreed, or if IBM provided the written statement that it requires.

I'm not sure that this will be needed for the public review of the specs (although it might be good, so the URLs in the spec resolve correctly), but we also need it for a decision a while back in the dormant OSLC Automation TC: https://lists.oasis-open.org/archives/oslc-automation/201508/msg00000.html

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


E-mail: martinpain@uk.ibm.com
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



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



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


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