Lists Home |
Date Index |
- From: David Megginson <email@example.com>
- To: XML Dev <firstname.lastname@example.org>
- Date: Tue, 11 Aug 1998 19:30:34 -0400
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
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
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 Megginson email@example.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)