Cart
[Home] [By Thread] [By Date] [Recent Entries]
Chris von See writes:
> Without a DTD or schema on which to "hang your hat", so to speak,
> you're vesting the application with the knowledge of what the
> various namespace-qualified constructs mean. This strikes me as a
> Very Bad Thing, because it leaves individual applications to
> interpret (potentially, interpret very differently) what a
> particular attribute or element means.
The situation that Chris describes exists with or without a DTD.
Imagine that I have a DTD containing the following:
<!ELEMENT body (title, p+)>
<!ELEMENT p (#PCDATA|emphasis)*>
I know where <p> is allowed to appear, and I know what it is allowed
to contain, but I know *nothing* more about what it means -- that
information is still hard-coded in an application somewhere.
I am a big fan of DTDs and have even written a book on them, but I
don't buy the 'discipline-of-writing-a-DTD-makes-you-think' model any
more than I buy the 'discipline-of-learning-Latin-makes-you-think'
model (and I enjoy reading Latin).
Namespaces actually help the problem a bit: they still do not tell me
what an element means (and I will be stunned if the result of the XML
Schema WG's work does that either), but at least they provide a global
point of reference. I do not know if <p> in document A and <p> in
document B are meant to have anything in common, but I do know that
(using James Clark's notation) <{http://www.megginson.com/ns/doc/}p>
in document A and <{http://www.megginson.com/ns/doc/}p> in document B
are meant to have something in common.
All the best,
David
--
David Megginson david@m...
http://www.megginson.com/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
