XML Inclusion Proposal

[Joshua E. Smith]

>  XML Node Inclusion Mechanism
>  ============================

As it happens, I've been working on an application which fits the
definition for "XML Processor" and have been thinking about inclusion.  So
this is quite timely, and I might even volunteer to be among the first to
implement it in a real application! ;)

An interesting philosophical question, first: if I make this inclusion
mechanism available to authors of documents in my XML conformant language
(which is not, I expect, a language which will be useful to any XML
processor other than my own), would it be reasonable to omit support for
general entity references?  I have no need for validation at the processing
end (that should be done at the editing/creation end of my system process),
so I've had no need up to this point to bother reading the external DTD
subset in my processor.  Your proposed inclusion mechanism is SO MUCH
simpler than doing the same thing in an external DTD subset; I know that my
authors would prefer to use that.  So, this question in a nutshell: If I
implement this proposal, I don't need to implement support for general
entities in external DTD subsets -- should I do so anyway, or are we really
on a path toward letting them wither and die?

Question 2: I think I understand your intent, but just to be sure: what do
you *expect* the included document to look like?  Does it start with:

<?xml version="1.0" encoding="UTF-8"?>

Would you expect it to have a DOCTYPE, or not?

Since you used the word "text" I suppose you might have been implying that
the included stuff isn't XML at all, but rather is just plain text, however
the linking bit leads me to believe that this is not the case.

I suspect I could just make my own rules for my authors (e.g., the included
document must be well formed, must not includes a doctype, etc.), but I was
wondering if you had a particular set of conventions in mind.  In
particular, a well formed document has only one root node, which might be
kind of inconvenient in a lot of cases (take your copyright example: I
might want to always include both a
<copyright>blah</copyright><GPL>blah</GPL> and if I require that the
included doc is well formed, I'd have to wrap those together, right?).

Question 3: I'm not familiar enough with the XLink/XPointer specs to
understand this part:

>Source Anchor:
>
>The source anchor may be identified as an anchor described in a locator
>with the role "source". It must address a single node in the same
>document as the link. If an inline link has no locator named "source",
>then the local resource serves as the source anchor.
>
>Target Anchor:
>
>The target anchor may be identified by a locator with the role
>"content". If the link has no such locator but it has only one  single
>remote resource then that resource may be used as the content anchor.

Can you give examples of each kind of inclusion this can lead to?  I'm
having a lot of trouble with understanding what these two paragraphs mean,
exactly.

Does this mean that I can include some miscellaneous nodes buried in the
included document?  For example, can I have a document license.xml with
various licenses, and then include the one in particular that I need by
using these anchors?  How would that look?

Sorry if these are dumb questions in the context of XLink/XPointer history,
but I'm not really familiar with any of that...


-Joshua Smith


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)