[
Lists Home |
Date Index |
Thread Index
]
- From: tpassin@home.com
- To: Amy Lewis <amyzing@talsever.com>, xml-dev@lists.xml.org
- Date: Wed, 09 Aug 2000 09:19:03 -0400
Yes, what would it mean for the included elements to be "valid'? For
instance, suppose I use an xxx:p element from my namespace
xmlns:xxx='urn:tp:my_own_bookformat'. If I simply insert the xxx:p element
in some foreign document, it wouldn't have been valid in the
my_own_bookformat system because a <p> has to be in a <section> that has to
be in a <chapter>.
To have a valid chunck of foreign xml, then, I would have to import
<xxx:chapter>1<xxx:section>1.0<xxx:p>...</xxx:p></xxx:section></xxx:chapter>
Even then it wouldn't really validate against the original DTD - even if the
DTD used the prefix 'xxx' - because there is no top-level element <book> as
called for in the DTD.
So what would it mean for the included stuff to be valid?
Presumably, it would mean "If this fragment had been embedded in a valid
structure according to its own DTD, this fragment would not cause the whole
structure to be invalid."
This sounds like a tall order for a processor to understand, and also a tall
order to describe in a DTD. It's funny, though, isn't it? All us humans
know pretty well what it would mean: e.g., if we put in an <html:h2>
element, we want a processor to display an h2 heading at that point **as
if** it were an html document. It's the formal aspect that's tough.
Maybe this is what should happen when a foreign xml structure is included,
if you are validating. The processor locates the DTD of the inclusion, but
builds its syntax starting, not at the start of the DTD, but at the included
elements(s). Thus, larger contexts would be thrown away, and only those
declarations in-scope for the elements of interest would be retained in the
final syntax. While we're doing this, we might as well have the DTD
processor implicitly add on the new prefix(s).
This approach would not have to change the specification for DTD syntax. It
would change the specification of DTD processing. However, you still
wouldn't be able to mix and match at will, since an xxx:p element wouldn't
necessarily be able to contain an svg element, for example (because this
woudn't have been allowed under the original xxx DTD).
Cheers,
Tom Passin
Amy Lewis wrote -
> 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.
>
> 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?
>
|