oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Proposed solution framework for handling OSLC URIs/identifiers on open-services.net -- FEEDBACK by 9/25
- From: Steve K Speicher <sspeiche@us.ibm.com>
- To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
- Date: Wed, 17 Sep 2014 12:53:14 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]