xml-dev - Re: Begging the Question (the novel)

[Lisa Rein <lisarein@finetuning.com>]

Greetings Uche:

Andrew wrote:
> 
> > Much of the fruitless debate has been caused by reading into
> > the specification things that it does not say.  If you strip away these
> > projections, what remains is less than has been fantasized but still much
> > more than nothing.

To which Uche Ogbuji replied:
> 
> This is arrant nonsense.  It almost seems as if you haven't been reading
> the thread.  Nothing inhuman, mind, I have such lapses quite often.  But
> it's pretty much beyond defense.

On the contrary. It almost seems as if you haven't been reading any of
the relevant specs covering these issues (XML Namespaces and XML
Schemas).  

Here's what I was able to determine from the XML Namespace
(http://www.w3.org/TR/REC-xml-names)and XML Schema Primer
(http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation)
specifications (1-6)


1) RE: http://www.w3.org/TR/REC-xml-names

The XML Namespaces recommendation states the following quite plainly
(and very politely too):

" [Definition:] The attribute's value, a URI reference, is the namespace
name identifying the namespace. The namespace name, to serve its
intended purpose, should have the characteristics of uniqueness and
persistence. IT IS NOT A GOAL THAT IT BE DIRECTLY USABLE FOR RETRIEVAL
OF A SCHEMA (IF ANY EXISTS)....However, it should be noted that ORDINARY
URLS CAN BE MANAGED IN SUCH A WAY AS TO ACHIEVE THESE SAME GOALS."

Translation:  The value of an XML Namespace URI doesn't have to be an
actual URL referencing an XML Schema, BUT IT COULD BE, if you wished to
implement it that way in an application.

This is an important and "good" thing.  The value of the XML URI isn't
REQUIRED to reference an actual schema, which means that the different
namespace-aware xml processors (both validating and non-validating) can
process each others' documents.

<simon>Yeah yeah yeah -- XML 1.0 processors aren't namespace aware
...and the sky is falling because of it...yadda yadda...back at
cha..etc. -- I'm trying to make a point here :-) </simon>



2)  If you wish to use the value of your XML Namespace URI to actually
reference a schema for validation,  you may. If you wish to use one of
XML Schemas' other built-in mechanisms for accomplishing such feats, you
may do that too. 

And if you don't require validation, and only intend to use Xml
Namespaces to disambiguate between a document's multiple vocabularies
(SVG/XML, MathML/HTML, etc.) ...You can do that too!  You have the power
to make those kinds of decisions in the future, as situations arise. 
Having these options is not merely a postive side-effect of some
ambiguity contained in the spec;  this scenario provides a text-book
example of XML's extensible architecture in action.

Such usages are clearly permitted by the relevant namespace and schema
standards, and constitute perfectly "legal" standards-compliant
implementations, and in no way qualify as namespace "abuses".  

3)The coast is clear with the XML Namespaces Recommendation, but how
does this new-fangled freewheeling philosophy stand up against the
requirements of XML Schema?     Answer:  It works like a charm.  

According to the Schema Primer Candidate Recommendation
(http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation),
XML Schemas provide SEVERAL different mechanisms that can be used to
provide the location of a schema for validating a document and
generating its "post-infoset contributions". (targetNamespace,
"include/schemaLocation", "import namespace", where the location of the
schema is the URL of the attribute value).

Like XML Namespaces, their use is completely OPTIONAL.  You may choose
to implement any one of them, or use more than one at a time, none of
them, or your own customized alternative.

In fact, the XML Schema Primer document practically encourages such
creative endeavors:

"The schemaLocation attribute contains pairs of values: The first member
of each pair is the namespace for which the second member is the hint
describing where to find to an appropriate schema document. THE PRESENCE
OF THESE HINTS DOES NOT REQUIRE THE PROCESSOR TO OBTAIN OR USE THE CITED
SCHEMA DOCUMENTS, AND THE PROCESSOR IS FREE TO USE OTHER SCHEMAS
OBTAINED BY ANY SUITABLE MEANS, OR TO USE NO SCHEMA AT ALL."

"Note that the schemaLocation is ONLY A HINT and some processors and
applications will have reasons to not use it; For example, an HTML
editor may have a built-in HTML schema. 

You may  also choose to not even use a namespace:

"A schema is not required to have a namespace (see Section 3.4) and so
there is a noNamespaceSchemaLocation attribute which is used to provide
hints for the locations of schema documents that do not have target
namespaces."


4) The Primer spec
(http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation)
practically encourages creative implementions for associating documents
with their XML Schemas. According to the Schema primer, as long as
conformant syntax is used, what your application uses to locate its
schemas is up to the implementor.   

"The author of an instance document, such as a particular purchase
order, may claim, in the instance itself, that it conforms to the rules
in a particular schema. The author does this using the schemaLocation
attribute discussed above. But regardless of whether a schemaLocation
attribute is present, AN APPLICATION IS FREE TO PROCESS THE DOCUMENT
AGAINST ANY SCHEMA. For example, a purchasing application may have the
policy of always using a certain purchase order schema, regardless of
any schemaLocation values."

5) As long as the document syntax, schema rules and validation/post
infoset contribution processes are implemented consistently, the end
results will be consistent across all XML 1.0
compliant/validating/namespace-aware parsers.  

As long as the mechanism used is successful at locating the schema and
validating a source file against it, the actual methods used to locate
the both files becomes less of an issue.  

In one situation, we might need our documents to be processed and
validated on the client using a schema that was downloaded from a
server. In a distributed Peer-to-Peer application, the schemas might
"live" on the end-users' hard drives, requiring a totally different
processing model. 

How the namespace URI value is used by an application is an
IMPLEMENTATION issue, and as long as the syntax is clean, it's a
friggin' free-for-all.



6)  All this fuss over the last two years seems to have been caused by
the fact that so many of us (myself included) were under the mistaken
impression that, since the namespace URI value wasn't REQUIRED to be a
URL, it also wasn't ALLOWED to be one. So us writer-types have to make a
few corrections to our earlier works -- it's a small price to pay for
finally getting it right and being able to now pass that correct
information on to our readers/students.  

Most of my students are beginners anyway, perfectly happy with using XML
Namespaces without really understanding the rationale behind each of the
subparts of their namespace declartion.  The "meaning" of the URI value
in question was just part of that big ugly declaration they know they
need to cut and paste into the root element of their document to get the
XSLT or SVG processors to work right.  

However, I probably gat asked that question from throughly puzzled
students more than anything else when I was teaching:  "Where does the
the namespace URI go to?" (Um. Nowhere.  I just looks like a URI.  It
isn't one.)
Why doesn't it go anywhere?  Could it go somewhere?  (No.  It could say
"ooga booga" and it would still work.)
Have I ever thought about maybe having it go somewhere?......(You get
the message)

Now I realize they were confused because I was confused :-)

***

In conclusion, this whole debate regarding how XML Namespace URIs
"should" be used appears to be a bit of a non-issue when the XML
Namespaces and XML Schema standards are taken into consideration.  
There are plenty of compatible options and most everything being
suggested so far appears to be "legal".  We can argue about which way is
better, but they all seem be "fair game".

The XML Namespaces spec wasn't deliberately under-specified or
intentionally vague because its authors were hoping to obfuscate the
shortcomings of an inherently faulty technology. (Why bother?) 

The mechanism described and its lack of restrictions regarding how the
value of the namespace URI is used isn't a "bug" or a limitation, but
rather a "feature" developed in the interest of interoperability :-)  

The namespace spec's functionality was already limited in scope without
placing any further restrictions on its how it might be used. (At the
time, the jury was still out for the most part among the xml expert
community-at-large regarding how XML Namespaces would actually be used.)

This isn't about a broken technology that's causing a hole in our hearts
we need to fill up with religion. 
It's about maintaining a programming philosophy of utilizing what is
available now while keeping our options open for the future.  Such a
strategy is "future-proofing" at its finest. 

I know it's not much, but it's about as good as future-proofing gets :-)
 
Peace,

lisa

http://www.finetuning.com
http://www.xml.com/resourceguide/


NOTE:  I've included a complete excerpt in the bottom of this message
from the XML Schema Part 0: Primer
(http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation) 
in order to provide a clear context for the quotes I've sprinkled
throughout this letter.

Disclaimer: I am aware that the "primer spec" i will be referring to in
below located at: http://www.w3.org/TR/xmlschema-0/     isn't really one
of the two "main" schema specs (structures and datatypes), but rather a
third, introductory-level explanatory specification (that is much better
written and easier to understand).  I thought it would provide a better
explanatory reference under the circumstances. 
If you would like to read through a more complicated, fairly confusing
explanation of the same material, the "real" spec is located at:
http://www.w3.org/TR/xmlschema-1/#schema-repr


**start excerpt

Here's the extended excerpt that the above quotes were pulled from at
URL:
http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#PO

5.6 schemaLocation 

XML Schema uses the schemaLocation and xsi:schemaLocation attributes in
three circumstances. 

1. In an instance document, the attribute xsi:schemaLocation provides
hints from the author to a processor regarding the location of schema
documents. The author warrants that these schema documents are relevant
to checking the validity of the document content, on a namespace by
namespace basis. 

For example, we can indicate the location of the Report schema to a
processor of the Quarterly Report: 

Using schemaLocation in the Quarterly Report, 4Q99html.xml 
              <purchaseReport
                xmlns="http://www.example.com/Report"
                xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
                xsi:schemaLocation="http://www.example.com/Report
                http://www.example.com/Report.xsd"
                period="P3M" periodEnding="1999-12-31">

               <!-- etc -->

              </purchaseReport>


The schemaLocation attribute contains pairs of values: The first member
of each pair is the namespace for which the second member is the hint
describing where to find to an appropriate schema document. THE PRESENCE
OF THESE HINTS DOES NOT REQUIRE THE PROCESSOR TO OBTAIN OR USE THE CITED
SCHEMA DOCUMENTS, AND THE PROCESSOR IS FREE TO USE OTHER SCHEMAS
OBTAINED BY ANY SUITABLE MEANS, OR TO USE NO SCHEMA AT ALL.

A schema is not required to have a namespace (see Section 3.4) and so
there is a
noNamespaceSchemaLocation attribute which is used to provide hints for
the locations of schema documents that do not have target namespaces. 

2. In a schema, the include element has a required schemaLocation
attribute, and it contains a URI reference which must identify a schema
document. The effect is to compose a final effective schema by merging
the declarations and definitions of the including and the included
schemas. For example, in Section 4, the type
definitions of Address, USAddress, UKAddress, USState (along with their
attribute and local element declarations) from address.xsd were added to
the element declarations of purchaseOrder and comment, and the type
definitions of PurchaseOrderType, Items and SKU (along with their
attribute and local element
declarations) from ipo.xsd to create a single schema. 

3. Also in a schema, the import element has optional nameSpace and
schemaLocation attributes. If present, the schemaLocation attribute is
understood in a way which parallels the interpretation of
xsi:schemaLocation in (1). Specifically, it provides a hint from the
author to a processor regarding the location of a schema document that
the author warrants supplies the required components for the namespace
identified by the nameSpace attribute. To import components that are not
in any target namespace, the import element is used without a nameSpace
attribute (and with or without a schemaLocation attribute). References
to
components imported in this manner are unqualified. 

Note that the schemaLocation is only a hint and some processors and
applications will have reasons to not use it; For example, an HTML
editor may have a built-in HTML schema. 

5.7 Conformance 

An instance document may be processed against a schema to verify whether
the rules specified in the schema are honored in the instance.
Typically, such processing actually does two things, (1) it checks for
conformance to the
rules, a process called schema validation, and (2) it adds supplementary
information that is not immediately present in the instance, such as
types and default values, called infoset contributions. 

The author of an instance document, such as a particular purchase order,
may claim, in the instance itself, that it conforms to the rules in a
particular schema. The author does this using the schemaLocation
attribute discussed
above. But regardless of whether a schemaLocation attribute is present,
an application is free to process the document against any schema. For
example, a purchasing application may have the policy of always using a
certain purchase order schema, regardless of any schemaLocation values. 

Conformance checking can be thought of as proceeding in steps, first
checking that the root element of the document instance has the right
contents, then checking that each subelement conforms to its description
in a schema, and so on until the entire document is verified. Processors
are required to report what checking has been carried out. 

To check an element for conformance, the processor first locates the
declaration for the element in a schema, and then checks that the
targetNamespace attribute in the schema matches the actual namespace URI
of the element (or, alternatively, that the schema does not have a
targetNamespace attribute and the instance element is not
namespace-qualified). 

Supposing the namespaces match, the processor then examines the type of
the element, either as given by the declaration in the schema, or by an
xsi:type attribute in the instance. If the latter, the instance type
must be an
allowed substitution for the type given in the schema; what is allowed
is controlled by the block attribute in the element declaration. At this
same time, default values and other infoset contributions are applied. 

Next the processor checks the immediate attributes and contents of the
element, comparing these against the attributes and contents permitted
by the element's type. For example, considering a shipTo element such as
the one in Section 2.1, the processor checks what is permitted for an
Address, because that is the shipTo element's type. 

If the element has a simple type, the processor verifies that the
element has no attributes or contained elements, and that its character
content matches the rules for the simple type. This sometimes involves
checking the character sequence against regular expressions or
enumerations, and sometimes it involves checking that the character
sequence represents a value in a permitted range. 

If the element has a complex type, then the processor checks that any
required attributes are present and that their values conform to the
requirements of their simple types. It also checks that all required
subelements are present, and that the sequence of subelements (and any
mixed text) matches the content model declared for the complex type.
Regarding subelements, schemas can either require exact name matching,
permit substitution by an equivalent element or permit substitution by
any element allowed by an 'any' particle. 

Unless a schema indicates otherwise (as it can for 'any' particles)
conformance checking then proceeds one level more deeply by looking at
each subelement in turn, repeating the process described above. 

***excerpt