<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.6000.16608" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>The below comments are posted here in case that
other users may have similar questions, so that they can get a
reference.</FONT></DIV>
<DIV><FONT face=Arial size=2>Question/Issue (Answer below)<BR>>> 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)<BR>>> because our
namespace os.optimizationservices.org is relative and not absolute.
However, my understanding is that relative namespace is <BR>>> still valid
but deprecated. See <A
href="http://lists.xml.org/archives/xml-dev/200103/msg00714.html">http://lists.xml.org/archives/xml-dev/200103/msg00714.html</A></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>> 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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>------------------------------------<BR>warning
message: <BR>$ xmllint small.osil (gives :)<BR>small.osil:2: parser warning :
xmlns: URI os.optimizationservices.org is not absolute<BR><osil
xmlns="os.optimizationservices.org" xmlns:xsi="<A
href="http://www.w3.org/2001/XMLS">http://www.w3.org/2001/XMLS</A><BR>------------------------------------</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Answer: <BR>In short don't worry about this
relative vs absolute namespace issue in OS. <BR>Briefly:<BR>1. Do the XML files
still conform to XML 1.0? Yes; no one suggests otherwise. They are all
well-formed.<BR>2. Do they conform to the namespaces spec? Yes again.<BR>3. Do
they conform to our own OSxL.xsd schemas? Of course, we all tested that.
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.<BR>In summary<BR>1.
os.optimizationservices.org is a valid uri; not only valid but also good
still.<BR>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.<BR>3. This
is URI -- not a URL that may lead somebody to think that there may actually be a
real location on the Web.<BR>Adding "http://" cause the extra confusion,
especially because we really don't have <A
href="http://os.optimizationservices.org">http://os.optimizationservices.org</A>
out there.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>If you read the deprecation note from W3C, it is
actually GOOD for us.<BR>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>"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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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"</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>In detail, in case if you are really curious, here
is an good explanation (not by me, but from the Wikipedia).<BR>... 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 <BR>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 ...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Hope it helps.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Jun Ma<BR></FONT></DIV><br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups "Optimization Services (OS)" group. <br> To post to this group, send email to optimizationservices@googlegroups.com <br> To unsubscribe from this group, send email to optimizationservices-unsubscribe@googlegroups.com <br> For more options, visit this group at http://groups.google.com/group/optimizationservices?hl=en <br> -~----------~----~----~----~------~----~------~--~---<br>
</BODY></HTML>
<br>