[OS] relative vs absolute uri in OS schema (for future reference in public)

[Jun Ma]

The below comments are posted here in case that other users may have similar questions, so that they can get a reference.
Question/Issue (Answer below)
>> Here is an issue we should address. One of our users is using libxml for parsing OSiL files. This package is throwing a warning (see below)
>> because our namespace os.optimizationservices.org is relative and not absolute.  However, my understanding is that relative namespace is 
>> still valid but deprecated. See http://lists.xml.org/archives/xml-dev/200103/msg00714.html

> Should we continue forward with a deprecated URI?  I think not, but this is something we should all agree on as it affects all of our schemas.

------------------------------------
warning message: 
$ xmllint small.osil (gives :)
small.osil:2: parser warning : xmlns: URI os.optimizationservices.org is not absolute
<osil xmlns="os.optimizationservices.org" xmlns:xsi="http://www.w3.org/2001/XMLS
------------------------------------

Answer: 
In short don't worry about this relative vs absolute namespace issue in OS. 
Briefly:
1. Do the XML files still conform to XML 1.0? Yes; no one suggests otherwise. They are all well-formed.
2. Do they conform to the namespaces spec? Yes again.
3. Do they conform to our own OSxL.xsd schemas? Of course, we all tested that. 

When I first put in the default name space years ago,  I remember I did think about this, i.e. no "http://" or any other scheme in the beginning. (really, our namespace had nothing to do with http://, we didn't even have the domain name or http Web site registered then!).  I was then even struggling with whether to use org.optimizationservices.os -- which looks like the Java package or C# namespace.
In summary
1. os.optimizationservices.org is a valid uri; not only valid but also good still.
2. it's a good uri to serve as a UNIQUE namespace, as I doubt there will be anybody else who use the same name that may cause conflict.
3. This is URI -- not a URL that may lead somebody to think that there may actually be a real location on the Web.
Adding "http://" cause the extra confusion, especially because we really don't have http://os.optimizationservices.org out there.

If you read the deprecation note from W3C, it is actually GOOD for us.
To deprecate the use of relative URI references in namespace declarations is to say that while they conform to the Namespace Recommendation of January 1999, later specifications such as DOM, XPath, etc. will define no interpretation for them.

"No interpretation" for me means treated AS IS. That is a relative reference such as "../abc", should be just treated as  "../abc". The warning in libxml is, for me, even a good warning. Just tells us that we should be careful, that libxml won't do anything with it, as it thinks it's relative.  Our intention is not that whether it's relative or absolute, rather libraries shouldn't resolve it to anything and as long as it's unique-- "resolving" means libraries that we use shouldn't append anything in the front or at the back. I believe, before, some old libraries will always try to resolve the relative namespace to absolute namespace -- not that we want.

I just tested several other xml libraries in Java and .net which are all dom2 and later compatible. The getNamespaceURI methods on the root element just returns "os.optimizationservices.org" -- Good. The javaDoc exlicitly says about this:This (namespaceURI) is not a computed value that is the result of a namespace lookup based on an examination of the namespace declarations in scope. It is merely the namespace URI given at creation time. -- since dom 2"

In detail, in case if you are really curious, here is an good explanation (not by me, but from the Wikipedia).
... namespace, an abstract domain to which a collection of element and attribute names can be assigned. An XML namespace is identified by a character string, the namespace name, which must adhere to the generic URI syntax [which all OSxL do]. However, the namespace name is not considered to be a URI because the "URI-ness" of strings is, according to the URI specification, based on how they are intended to be used, not just their lexical components. A namespace name also does not necessarily imply any of the semantics of URI schemes; a namespace name beginning with "http:", for 
example, likely has nothing to do with the HTTP protocol. There has been much debate about this among XML professionals on the xml-dev electronic mailing list; some feel that a namespace name could be a URI, since the collection of names comprising a particular namespace could be considered to be a resource that is being identified, and since the Namespaces in XML specification says that the namespace name is a URI reference. The consensus seems to be, though, that a namespace name is just a string that happens to look like a URI, nothing more ...

Hope it helps.

Jun Ma

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Optimization Services (OS)" group.
To post to this group, send email to optimizationservices at googlegroups.com
To unsubscribe from this group, send email to optimizationservices-unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/optimizationservices?hl=en
-~----------~----~----~----~------~----~------~--~---

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/os/attachments/20080220/9836aeda/attachment.html