[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Namespace use cases

  • From: rjelliffe@allette.com.au
  • To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
  • Date: Sat, 11 Jul 2009 23:58:01 +1000 (EST)

Re:  RE: Namespace use cases
> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.