xml-dev - Re: Does DTD validation work with namespaces?

["Winchel 'Todd' Vincent, III" <winchel@mindspring.com>]

> On Wed, Aug 09, 2000 at 07:41:05AM -0400, Norman Walsh wrote:
> >/ James Robertson <jamesr@steptwo.com.au> was heard to say:
> >| Isn't the issue that namespaces allow you
> >| to mix information from a number of sources,
> >| however you see fit? Every document can have
> >| different elements, and yet still be considered
> >| OK according to well-formed and namespace rules ...
> >|
> >| How do we handle _this_ behaviour, and still
> >| make some use of DTDs?
> >
> >The only way that I'd consider such a document valid is if the (set of)
> >DTDs in question all referred to each other. I would expect the content
> >models of each DTD to specifically allow the mixtures. For example,
> >a DocBook+MathML DTD might allow:
> >
> >  <!ELEMENT equation (alt?, (graphic+|mediaobject+|mml:math+))>
> >
> >But to say that you can mix them "willy nilly" violates the principals
> >of validity at their core.

<AmyLewis>
> Oh, yuck!  (to use the technical term)
>
> A treatise combining elements of mathematics, chemistry, with
> illustrations and bibliographic information can't be written?
>
> SVG, at least, is intended for inclusions, rather than for the creation
> of standalone documents; is this inclusion only via XInclude/XLink?
>
> Or could I create a grand-unifying DTD for work in the field of
> statistical chemistry (say) that, by importing the domain-specific DTDs
> for mathematics, chemistry, graphics, bibliographies, and general
> document-oriented text, permitted all of these elements, in some
> specified (to whatever degree of specificity) order?
>
> Or must I say, "Nope, can't do that," and "just" do XHTML?
</AmyLewis>

Amy's vision is my own.  For example . . .

Within a "Legal" set of namespaces, (Court Filing, Contract, Transcript), if
the same legal industry consortium defines the namespaces, then they
*should* work together as Norman suggests.

However, I agree with Amy and disagree with Norman in the following respect
. . . Suppose there is a Contract DTD (defined by a legal industry
consortium) that defines contract clauses and a contract vocabulary.
Amazon.com or some other e-commerce site wishes to mix elements from the
Contract DTD into their website mark-up, or an Amazon invoice, or standard
prospectus mark-up with an independently created DTD defined by some other
organization, or anything else that the legal industry consortium does not
know about (and did not consider when it created Contract DTD), then this
would be perfectly *appropriate* and, indeed, exactly what the goal should
be.

Norman, you missed the point when you replied:

/ "Winchel 'Todd' Vincent, III" <winchel@mindspring.com> was heard to say:
| It seems to me that URIs would be the right answer if there were a
| one-to-one relationship between URI and namespace prefixes, rather than a
| one-to-many relationship (i.e., unique prefixes via a fixed association
with
| a URI).

<Norman Date="2000.07.25" Subject="Re: Question About Namespaces and DTDs">
If there was a one-to-one relationship, then the URIs would be
unnecessary, the prefixes would be enough. But any proposal based on
the notion of standard prefixes amounts to little more than adding
another name character to XML. And that's just not enough.
</Norman>

You took the above paragraph out of context.  In the previous email, I also
wrote:

<ToddVincent Date="2000.07.25" Subject="Re: Question About Namespaces and
DTDs">
I have been thinking that it would also be nice if there were some
requirement (perhaps an optional feature in parsers) that allowed one to
fetch the schema/DTD at the end of the namespace URI.  If there were at
least a moral responsibity on the owner to keep the schema/DTD at the end of
the URI the same (or tell people when it changed) (or a perhaps a
responsibility on the user to hash/sign it, so you know if it has changed),
then namespaces would be tied to a vocabulary that gave them meaning (now
and in the future), rather than simply being a means of avoiding technical
element collision.  This is what I thought "semantic web" meant and was
disappointed to find it didn't.
</ToddVincent>

My understanding is that URI's can't be parsed, but prefixes can.  Prefixes
don't have a well-defined means of pointing to web resources.  So, prefixes
and URIs are very different.  A one-to-one mapping of them makes a lot of
sense if you want to use the prefixes on elements you want to parse and also
use the associated URI to point to a DTD or Schema that gives the elements
some meaning.  (Please correct me if I'm making any technical mistakes
here.)

If well-formed Contract XML (defined by X consortium), embedded within
Invoice XML (defined by Y consortium) points to a standard, fixed,
well-known DTD or Schema, which in turn references a specification (or
another Schema perhaps) that explains it, then I think Norman's conceptual
problem begins to go away and we start to have a "semantic web."

There are really two different, but related issues here.  (1) Namespaces
don't work as a technical matter if you want to validate DTDs (2) Namespaces
don't work very well conceptually, even if they work technically, whether
you use DTDs or Schemas, because there is no requirement or even expectation
of uniqueness (unless you work within your own closed little world), so when
you start mixing and matching elements from different schemas that you don't
know about, you get a jumbled mess of elements that may *technically* work,
but has no meaning (or at least a meaning that is very uncertain and that is
subject to change at anytime).

This conversation is very stimulating.  Thanks.  :-)

Todd