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

[Marcus Carr <mrc@allette.com.au>]

keshlam@us.ibm.com wrote:

> Namespaces are NAME spaces. That's all. Folks read all sorts of other
> implications into namespaces, and everyone has their own ideas about what
> they want to do with namespaces, but namespaces themselves (a) are just
> naming and (b) make no particular effort to be compatable with DTD
> validation. There was a fairly explicit assumption that if you were using
> Namespaces, you would either work with well-formed documents or with a
> namespace-aware schema language, _NOT_ with DTDs. If you insist on mixing
> the two, and it doesn't work well, the response is going to be "we know."

You're not giving us much credit - most of the participants of this thread are
(I think) well aware of the issues. What we're driving at is the inclusion of a
fragment of a document from a second DTD that may be the same or different than
the first. I would like to be able to do something like:

<!DOCTYPE Foo SYSTEM "Foo.dtd">
<Foo>
  <Bar>This is a Bar suddenly interupted by a
    <!DOCTYPE Boo SYSTEM "Boo.dtd">
    <Boo>This is my Boo element</Boo>
  </Bar>
</Foo>

(Whether the mechanism was a PI or DOCTYPE declaration is irrelevant - I used a
DOCTYPE for clarity.)

After processing the document, I might want the following output:

<Cat:Foo>
  <Cat:Bar>This is a Bar suddenly interupted by a
    <Dog:Boo>This is my Boo element</Dog:Boo>
  </Cat:Bar>
</Cat:Foo>

I understand that it's not practical to try to process the namespaced instance
- I'm more interested in looking further up the chain to the origin. As you
point out, the namespaced document is intended to be the result, probably to be
used as a well-formed document only - I'm happy with that. What I want is a
mechanism that allows me to produce such a document from valid fragments.

> If the tagsets have a clear boundary between them -- in other words, if you
> aren't attempting to permit completely arbitrary interleaving of languages
> -- there's also the solution of using ANY in selected places and having
> your application logic explicitly check those to apply more intelligence at
> those specific points.

That's not much of an option - ANY has never been anything short of plug-ugly.

> Basically, the "publisher's gumbo" model of saying "I want to be able to
> drop MathML takes anywhere inside an SVG graphic embedded anywhere within
> an HTML document -- or vice versa" just doesn't fit the concept of
> Validation in the first place. If you really want the parser to provide
> some validation assistance, you need to give it a specific grammar for the
> document. If you can't describe that grammar precisely, validation can't do
> anything for you.

I can easily describe the grammer, but a validating application isn't allowed
to process it. It's not correct to just lump all of these cases into a term
like "publisher's gumbo" - there are a lot of cases where there are legitimate
and substantial benefits available from being able to build compound documents.
One off the top of my head would be the ability to include a fragment of law in
a case report - we're not trying to build magazine pages.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein