OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

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

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

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


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:

Download Document: 


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,


XML Schema(s)
This version:

seen in this draft RDDL document:


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


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

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

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


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 '#'):


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


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


to identify/name faults, functions, etc:


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

Please feel free to contact me with any questions.


Robin Cover

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

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

[2] note on avoiding collisions


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


"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"



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

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