Re: Is there an elegant way to copy a DOCTYPE declaration from one docto another?

["Jonathan Borden" <jborden@xxxxxxxxxxxx>]

Mike Brown wrote:


> Jonathan Borden wrote:
> > What you are doing in your article and what I am doing in XSet is
creating
> > an XML expansion of the XML data model which itself fits into the XPath
data
> > model. XSet expands the entire XML property set into a set of elements
and
> > attributes, including things like PEs, GEs, internal and external
subsets,
> > whitespace, delimiters etc, etc, etc etc.
> >
> > A good reason this is useful is for this exact case: to allow XPath, and
> > hence XSLT to operate on information which is otherwise lost.
>
>
> Part of the idea of XML is that your document can be split among multiple
> entities. Does the metadocument that conforms to your schema represent the
> complete document, the complete set of entities, or just the document
> entity?
...
>
> root
>   |__element 'myData'
>        |__text '\n  '
>        |__element 'foo'
>        |    |__text 'Hello World'
>        |__text '\n  '
>        |__element 'bar'
>        |    |__text 'Hello World'
>        |__text '\n'
>
> ...might actually be produced by the following set of entities:
>
> <?xml version="1.0" encoding="utf-8" standalone="no"?>
> <!-- doc.xml, the document entity -->
> <!DOCTYPE myData [ <!ENTITY moreDeclarations SYSTEM "dtd2.dtd"> ]
>   SYSTEM "dtd1.dtd">
> <myData>
>   <foo>&stuff;</foo>
>   &morestuff;
> </myData>


    For entity expansions within the body content, this is represented
within the  (RDF) Alt construct, here simplified for clarity e.g.:

<element><Name>myData</Name>
    <element><Name>foo</Name>
        <Alt>
            <EntityDef><Name>stuff</Name></EntityDef>
            <string value="Hello World"/>
        </Alt>
    </element>
    <Alt>
        <EntityDef><Name>morestuff</Name></EntityDef>

<EntityRef><ExternalID><SystemLiteral>bar.xml</SystemLiteral></ExternalID></
EntityRef>
        ... contents of bar.xml goes here ...
    </Alt>
</element>

>
>
> Even if you combine these into a single metadocument, is your XPath tree
> going to be a representation of the metadocument's document element and
> its contents, or is it going to be the simple tree above, plus some other
> info available through functions?

   When full fidelity is required, both are included using Alt.
>
> Conceptually I think one of the tenets of XML is to 'physically' model an
> abstract tree of data. What you're doing is making an abstract tree of
> data that models a document that in turn models a document (or entity set)
> that is modeling an abstract tree of data.

    Actually it is an abstract tree of the XML parse tree as described in
XML 1.0.

> *boggle* I really don't like
> the idea of having to write a stylesheet that operates on an XPath tree
> that is not analogous to the tree represented by the complete, original
> document.
>
    You don't have to. You currently write stylesheets that operate on the
original document. But, and this is a big but, XPath has a specific data
model which includes only certain specific parts of this original document
parse tree ... the abstract parse tree has been already pruned and condensed
before it gets to the XPath processor. That's why SAX means the "Simple API
for XML", if it fired every XML production then it wouldn't be simple. SAX
and XPath are designed for the 95% of applications which only need to deal
with the subset which is in the XPath data model. XSet describes the full
expanded tree. It expands the tree so that EntityRefs become elements for
the very specific reason that XPath understands elements, not native
EntityRefs.

    Now the reason I might want to use XPath/XSLT on this expanded tree is
to:

a) express constraints on a particular data model
b) define subsets and condensations of the XSet: e.g. the Infoset
c) transform XSet itself into e.g. an XML Schema Definition
etc. etc.

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list