[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: EMBED and validation
>-----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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|