Lists Home |
Date Index |
- From: Gavin McKenzie <gmckenzi@JetForm.com>
- To: "'email@example.com'" <firstname.lastname@example.org>, "'email@example.com'" <firstname.lastname@example.org>
- Date: Wed, 3 Dec 1997 09:25:21 -0500
>From: email@example.com [SMTP:firstname.lastname@example.org]
>Sent: Tuesday, December 02, 1997 11:00 PM
>To: Gavin McKenzie; 'email@example.com'
>Subject: RE: EMBED and validation
>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.
>[Gavin McKenzie] That's fine. I didn't expect the parser to do this work
>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.
>[Gavin McKenzie] Well, I know about my software...but I don't want to do
>anything that would make it unduly difficult somebody else to write their own
>application to process my XML. If I can't follow the letter of XML in this
>respect, because it doesn't define this particular behaviour, then at least I
>wish to stick to the spirit. I don't want somebody who is considering
>writing their own ad-hoc XML processor to operate upon my XML to think,
>"Gee...this Gavin guy really missed the point" and decide it's too difficult
>or doesn't 'feel' like XML.
>> 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.
>[Gavin McKenzie] Understood. Parser based inclusion no, application
>>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?
>[Gavin McKenzie] see next comments.
>>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...
>[Gavin McKenzie] I'd prefer that these shops NOT write out fixed length
>I'm seeing the phrase 'XML hyperdocuments' in recent postings, and this seems
>to fit my bill of requirements. Imagine an application that is intended to
>produce a report of hazardous materials -- this application is going to write
>out an XML document that contains the various line items for each package of
>haz-mat and write in a linkage to another XML document that contains safety
>and handling instructions. The wished-for final results is a
>displayed/printed report with the safety instructions interleaved in-situ
>between the line items.
>It is very convenient for the application that produces this XML document to
>write out the links along the way, rather than predict them and write them
>into the top of the document as entities. Writing out entities before hand
>would be viewed as unacceptable because it most likely constitutes a second
>So the links may be written with AUTO/EMBED, but it is up to the application
>to decide to validate the linked content, knowing that this behaviour is not
>defined within the spec.
>Anyway, I've concluded that it's ok for my application to resolve these
>linkages (in a manner that seems like inclusion) and create a new virtual
>document for the purpose of display. And, it's ok for my application to
>interpret EMBED as it chooses (gulp).
>But, this notion of hyperdocuments...who is working away at this? Pardon my
>ignorance, but is this what the Hy in HyTime stands for? And would a future
>layering of this technology onto XML be the answer to the hyperdocument
>problem? I can only hope it is simple enough for mortals given that the this
>group seems to not even expect most XML processing applications to be capable
>of XPointer processing.
>>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
>[Gavin McKenzie] Thanks for the help.
>David Durand firstname.lastname@example.org \ david@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:email@example.com
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:firstname.lastname@example.org the following message;
>To subscribe to the digests, mailto:email@example.com the following message;
>List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)