[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: EMBED and validation

  • From: Gavin McKenzie <gmckenzi@J...>
  • To: "'dgd@c...'" <dgd@c...>, "'xml-dev@i...'" <xml-dev@i...>
  • Date: Wed, 3 Dec 1997 09:25:21 -0500

embed doesn t validate


>-----Original Message-----
>From:	dgd@c... [SMTP:dgd@c...]
>Sent:	Tuesday, December 02, 1997 11:00 PM
>To:	Gavin McKenzie; 'xml-dev@i...'
>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@c...  \  david@d...
>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@i...
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@i... the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@i... the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@i...)
>

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.