Namespace Processing Hints and Rant on Scoping/Defaulting

[David Megginson]

John Cowan writes:

 > The trouble arises in this case:
 > 
 > 	<foo:thing>This thing belongs to URI A</foo:thing>
 > 	...
 > 	<foo:thing>This thing belongs to URI B</foo:thing>
 > 
 > where the same prefix is meant to map to more than one URI in
 > the course of the document.  The DTD can't supply "xmlns:foo"
 > default attribute values for both foo:a elements, because to
 > a DTD they are the same element type.

[I will continue in my role as a _very_ reluctant defender of the new
WD.]

This is a problem with defaulting, not with validation -- although
DTDs can do both, the two are distinct.

Exactly the same problem occurs with architectural forms, where you
might want to derive an element of the same type from different
architectural forms at different points in a document.  From the
perspective of DTD design, you have three major choices:

1. Provide a non-#FIXED default value, allowing the user to specify a
   different value when necessary.

2. Make the attribute #REQUIRED, forcing the user to specify a value
   every time.


3. Make the attribute #IMPLIED, allowing the user to specify a value
   only when necessary.

With AF's, you can also use an enumerated value to limit the
possibilities, but few URNs would fit the constraints of an XML name.

 > > That said, I still really HATE the new declaration namespace syntax
 > > and the scoping/defaulting, but for reasons other than the problem of
 > > DTD validation: the whole thing reminds me too much of my first early
 > > experiences with BASIC, assembly language, etc., when people were
 > > writing giant, monolithic programs to avoid the supposed overhead of
 > > function calls.  Today, some people want to build giant monolithic XML
 > > documents to avoid the supposed overhead of multiple HTTP fetches.
 > 
 > I can't agree with you.  The utility of namespaces is not so much
 > to create merged documents, but to create documents representing
 > merged designs: in particular, namespaces allow documents to
 > "mix in" existing element semantics as and where needed.
 > The alternative is to invent your own elements and "just know"
 > (namely, encode in programs) what their semantics are.

We're talking about different things: I *like* the logical model
behind namespaces (which is what you're describing), but that has
nothing to do with the particulars of declaration syntax or local
scoping and defaulting.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)