xml-dev - RE: EMBED and validation

[Gavin McKenzie <gmckenzi@JetForm.com>]

>-----Original Message-----
>From:	dgd@cs.bu.edu [SMTP:dgd@cs.bu.edu]
>Sent:	Tuesday, December 02, 1997 11:00 PM
>To:	Gavin McKenzie; 'xml-dev@ic.ac.uk'
>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 me.
>
>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
>behaviour yes.
>
>>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
>to change.
>
>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
>records.
>
>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
>pass.   
>
>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              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
>Boston University Computer Science        \  Sr. Analyst
>http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
>--------------------------------------------\
>http://www.dynamicDiagrams.com/
>MAPA: mapping for the WWW                    \__________________________
>
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)