EMBED and validation
David G. Durand
dgd at cs.bu.edu
Wed Dec 3 04:02:38 GMT 1997
I've reordered your mail for ease of response.
At 12:56 AM -0000 12/3/97, Gavin McKenzie wrote:
>Just some comments on this issue of 'inclusion'. I apologize if this
>sounds like a ramble...
>Although one thing remains unclear, despite the dozens of submissions
>I've read: Is it, or is it not acceptable for an application to choose
>to act upon an XLL linkage in a way that causes the target linked
>content to be included and validated.
I must have been rambling too much. No. It is not part of XML validation to
performn such a step. Your application is free to implement any checks it
reuqires (that the linked data is a well-formed XML tree, and that that
subtree would be legal if put in place of the link). XML will give you no
aid in such checking other than maybe providing the code to help you
implement these checks.
For that reason, I would not recommend doing this unless you know exactly
what software will run across your data, or you can write a stylesheet to
perform your required validation.
> Another way, if I create an XML
>derived format, and document that a processor of this derived format
>should view a particular usage of an XLL construct as instructions to
>"retrieved and include 'inline' the target content, and validate it
>against the originating document's DTD as if the target content was part
>of the original document".
The retireve and view part yes, the validate part is a no, unless you
provide the code for that step. It's not a part of XML. If you need XML
parser-based inclusion you have to use entities.
>I understand the purpose and usefullness of declaring an entity in the
>internal DTD subset and employing this mechanism as the proper and valid
>way to include some (potentially marked up) text. But, echoing Rob
>McDougall's closing statements, for *many* applications it is simply too
>difficult for the application to 'predict' these inclusion points and
>place a corresponding declaration in the internal DTD subset. In fact,
>I would venture to say that most of my customers would walk away from
>XML based on this issue alone.
I don't fully understand why, which is not to say that I don't believe you.
XML does not have another mechanism for textual inclusion. Some already
believe that one mechanism is too many, so I don't know how likely this is
Why is this a show-stopper four your application?
>Heavens, so many data processing shops still want to continue writing
>data out in fixed length COBOL style records; and while it may be the
>nineties, they are resistant to change. As much as it may seem to be a
>stretch to bring these type of data producers into the XML world, I
>(naively) think it is possible.
fixed length records aren't such a problem for XML, but I suspect you have
soemthing else in mind...
>So, after reading all the previous submissions (especially Peter's
>display of the overhead for setting up a GIF reference via the external
>entity method) I too wish to use an XLL based mechanism for expressing
>an 'inclusion' linkage, and pine for some agreement on the semantics.
Peter's example would be a great deal simpler, if he moved the element and
notation specifications into the DTD, rather than keeping them in the
subset. Since it is a validity constraint, and not a well-formedness
constraint that a NOTATIONs be declared, they can be banished to the DTD,
and the stylesheet can use the notation name to decide processing.
David Durand dgd at cs.bu.edu \ david at dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________
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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev