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
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
- Date: Thu, 1 Oct 2015 16:38:58 +0100
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 |
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]