[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: -------------------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]