Re: [xml-dev] RE: Namespace use cases

[rjelliffe@allette.com.au]

> Just a quick comment on one of your points, Rick.

Delighted.

> At 2009-07-11 20:06 +1000, rjelliffe@allette.com.au wrote:
>>The second is the namespaces used for Qnames in element and attribute
>>values. XSLT went one way, but I think it is the wrong way because it
>>fudges the difference between data and markup. Schematron has explicit
>>elements and this has been very smooth: developers don't worry about
>>default namespaces, they only need to look in a single place.
>
> I long regret the Schematron choice of using elements for declaring
> namespaces and their prefixes.  In every other application of XML I
> use the namespace axis and namespace facilities to obtain the
> information I need to support XPath addresses that are in attribute
> values,

Not so. In XSD for example you also need to look up the
attributeFormDefault, elementFormDefault, the targetNamespace attribute
and whether any imports have namespace attributes.

> but for Schematron I have to do something different than for
> everything else.  So now instead of looking in a single place for
> namespaces (the namespace axis) I now have to look in a second place
> (the newly-introduced Schematron elements).
>
> I've always been uncomfortable with that.  I do not find it "smooth" at
> all.

Data is data, not markup.  You should not have to alter the data in order
to fit in with the markup being used.

There is nothing in the Namespaces spec that says it should be applied for
data, and there are no schema languages that even allow this to be
declared in a transparent fashion.  DOM didn't even support namespaces.
XSLT1's namespace implementations were unreliable. XSLT has adopted a
different system again.

In Schematron you know where to find the namespaces no matter what version
of DOM, XSLT 1, XSLT2 etc you are you using. And you don't need to look at
any scope or imports or defaults to figure things out.

And, more importantly, there is no mucking about with default namespaces.
By keeping the data and the markup strictly separate, there is no problem
with using the default namespace for the schema elements and making
constraints on data with no namespace. This cannot be done otherwise. For
example:

 <schema ... xmlns="http://purl.oclc.org/dsdl/schemaatron";>
  ...
  <rule context="html">
     <assert test="head">And html element should have a head</assert>
  </rule>
  </schema>

Why is the namespace used for a qname in data any different from, say, the
units of measure used in a document?  It would be perfectly feasible to
instead having  width="1 cm" having width="1" plus units="cm" then
allowing that to find the units you should look up  
ancestor-or-self::*[@units][1]/@units    --indeed, SVG has all sorts of
scoping like this though not exactly this-- but it introduces an
unnecessary generality.

Cheers
Rick Jelliffe