Re: [energyinterop] Groups - RDDL for the energyinterop namespace(energyinterop.htm) uploaded

[Robin Cover <robin@oasis-open.org>]

On Wed, 29 Jul 2009, davidcwilson@trane.com wrote:

--------------------------------------------------------------------------------
http://lists.oasis-open.org/archives/energyinterop/200907/msg00067.html

The document named RDDL for the energyinterop namespace (energyinterop.htm)
has been submitted by Mr. David Wilson to the OASIS Energy Interoperation
TC document repository.

Document Description:
This is a draft of the RDDL.  It currently only references the
EventInfo.xsd document.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=33572

Download Document: 
http://www.oasis-open.org/committees/download.php/33572/energyinterop.htm

--------------------------------------------------------------------------------

I have not been tracking closely with proposed namespace URI and "information
resource" URI design in this group, but I think I did spot a couple instances
where it's proposed that XML schema definition files and other file-system
resources be located in a URI hierarchy beneath a proposed /ns/ path,

viz.,

XML Schema(s)
EventInfo.xsd 
http://docs.oasis-open.org/ns/energyinterop/energyinterop-20090701/EventInfo.xsd
This version:
http://docs.oasis-open.org/ns/energyinterop/energyinterop-20090701/EventInfo.xsd

seen in this draft RDDL document:

http://www.oasis-open.org/committees/download.php/33572/energyinterop.htm

Now, personally (unofficially), I see no problem with the proposed XML NS URI 
as:

   http://docs.oasis-open.org/ns/energyinterop/energyinterop-20090701

However, the OASIS Naming Guidelines, sub the Section with title 
"XML Namespace Design, Allocation, and Management" [1]

clarifies that URIs should not be created for file system resources downstream
(in the path hierarchy) from the Namespace URI containing the /ns/ component

This is specified as a means of avoiding collisions [2] at the point of the
XML namespace URI terminal, which can be a "slash" variant ending with "/"

Here's an expanded summary from the Naming Guidelines, using
slightly improved pseudo-syntax for the variables vs. literals

NS URIs must be rooted at the "docs.oasis-open.org" Internet domain
using one of the following two patterns containing the literal
/ns/ path element, unless an alternative URI is approved by the TC Administration:

(1) http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String> OR
(2) http://docs.oasis-open.org/<ShortName>/ns/<Versioned-NS-String>.

Where: <ShortName> is the approved short name for the TC or Member Section;
<Versioned-NS-String> is a short string identifying a namespace using
a versioning subcomponent [and where a versioning subcomponent could be
a string encoding a date, cardinal-number-identifier, etc]

But: TCs should avoid creating collision/confusion and semantic
overloading at the point of a XML Namespace URI which could be
mistaken for a regular directory URI, or vice versa; thus,
for any Type 1 or Type 3 HTTP scheme namespace URI terminating
in

a) ...<Versioned-NS-String>      /* OR */
b) ...<Versioned-NS-String>/

no URIs should be created for information resources matching "*" in

http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String>/*
http://docs.oasis-open.org/ns/<ShortName>/<Versioned-NS-String>/<OtherPath>/*

Example: using an imaginary TC with <ShortName> 'ws-xx' and a
<Versioned-NS-String> with value 'WS-XX-20080115', we could create
an XML Namespace URI of these types (also with terminal '#'):

http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/
http://docs.oasis-open.org/ws-xx/ns/WS-XX-20080115
http://docs.oasis-open.org/ws-xx/ns/WS-XX-20080115/

but we will not create a (literal) file-system object
(folder/directory) 'WS-XX-20080115' and we will therrefore
also not install any information resources on the file
system matching '*' based upon some imaginary directory
'WS-XX-20080115':

http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/*
http://docs.oasis-open.org/ws-xx/ns/WS-XX-20080115/*
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/<OtherPath>/*
http://docs.oasis-open.org/ws-xx/ns/WS-XX-20080115/<OtherPath>/*

The HTTP scheme XML namespace URI is put in a reserved path,
and it may be used as a base URI for related properties, functions,
messages, faults, dialects (etc) which merit identification using
URI references, where these URIs identity non-information resources.

For example, a TC might define URIs based upon the NS URI

http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/

to identify/name faults, functions, etc:

http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/faultFoo
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/faultFaz
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/functionFizzle
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/propertyBar
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/messageBaz
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/messageBaz/Revoked
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/dialectSnark
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/signalBlort
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/signalBlort/Blarney
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/signalBlort/Blarney/01
http://docs.oasis-open.org/ns/ws-xx/WS-XX-20080115/signalBlort/Blarney/02

In the current OASIS server implementation for XML namespace URI handling,
requests to the server for a resource matching a NS URI or
derived (function, fault) name will be handled as a URI rewrite
(resolving) to the resource serving as the namespace document, viz., a
textual document [3] which documents the XML Namespace URI (what
groups owns is, what specifications declare or use it, what
policies govern its versioning, etc).

Note: in the future, we may modify OASIS practice to use (or allow for)
redirect of an HTTP scheme NS URI to the namespace document URI (HTTP Status
code 303 or other), as recommended in a W3C TAG Finding on
"Associating Resources with Namespaces":

"We recommend that in all such cases server configurations
should be changed, in line with [HTTPRANGE], to respond
with a 303 redirection from the namespace URI to a related
URI for the namespace document...."

Details: http://xml.coverpages.org/ni2008-06-26-a.html
          http://www.w3.org/2001/tag/doc/nsDocuments/

Please feel free to contact me with any questions.

Cheers,

Robin Cover

=========== References:

[1] http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#NamespaceDesign

[2] note on avoiding collisions

http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#uri-overloading

[3] HTTP scheme NS URIs must resolve under DNS+HTTP

http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV08.html#urisMustResolve

"HTTP scheme namespace URIs must resolve to some informative
resource, ideally meeting the requirements for a (RDDL)
namespace document; OASIS will supply a default namespace
document if the TC designates/supplies no resource for resolution"

   http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentaryV08.html#resolution
   http://www.w3.org/TR/webarch/#namespace-document

-- 

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/who/staff.php#cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783




PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration