Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: EMBED and validation
 At 9:16 AM -0000 11/28/97, Peter Murray-Rust wrote: >You approve that it must/needNot be XML. For me the latter is essential. >Sometime ago I proposed an extra attribute MIME to describe the MIME type >of the target HREF. (Note that this is NOT always available from >contentType since it may be a local file. If this doesn't get into the >SPEC, I suggest we need an XDEV attribute and I proposed that 2 days ago... That's what NOTATION is for. Use an external entity, and makes its notation be the MIME type of the content, and then you're all set. >The more I think about this, the more I think we have to delineate the >possible actions and systematise them here. I think some people will want >to treat XML-LINK as simply like HTML, others will want automatic >inclusion. Since I am not a hypermedia expert, I am hoping to get some >guidance. This is all a question for the stylesheet/processing langagues, and not for XML per se. >>Is the application supposed to treat this chunk as (hopefully) well-formed >XML >>in a separate parsing process? Would it be legitimate for an application to > >As with all tricky questions on XML the answer is 'application-dependent'. >So - if we can agree some semantics here that would be very helpful. not strictly correct. the stylesheet processing is application dependent. The validation is _not allowed_ as part of XML validation. You can of course require that your application limit the valid XML documents that it will process, but then you are limiting the documents that it will process, which may not be a good idea. >>fold EMBEDded chunks into the document containing the link for purposes of >>styling in particular but also validation in certain circumstances? Many > >Yes, if the application has been written to do so :-) Styling yes, validation no. >I shall make something like this available in JUMBO. All the guts are >there, it's just agreeing on the public face - i.e. whether there is an >XDEV attribute > >Again it may be possible to request the application to supply styling and >DTD (e.g. through an XDEV attribute or PI). Again I'd like to see public >discussion on this. For an XML document, you can refer to the whole document and use extended pointers to pick out the linked sub-part -- this lets you get DTD, and content-type (via NOTATION). >>My instinct is to be as conservative as possible and make sure that all XML >>chunks EMBEDded by a link could be folded into the linking document without >>making it invalid, but this is a more radical constraint than I expect most This is not consevative, but radical, sit it imposes an ad-hoc constrain on linking, based on a limited processing model. >I think it is far better to have the semantics explicit and in the open, >rather than for different application developers to think what is best >here. This is an area where - without XDEV - we have severe problems of >interoperability. I know that a lot of people think that interoperable XML >applications is Quixotic, but *I* believe it's possible if we have the >communal will. Otherwise the average user will pick up application A and >find their HREFs folded in and swear and curse when application B doesn't. >Remember, if you don't like what I'm suggesting, you don't even have to >read it :-) No, interoperable in the sense you mean (interoperable without a particualar stylesheet to interpret against) is in fact a gigantic mistake that XML is designed to help peopole avoid. The point of XML is to separate rendering and other processing from document representation and semantics. This means that no viewer can process an XMl document for display wothout a separate specification of what display is desired. It will be possible to test application compatibility when applications take XSL document + XML document pairs. An XML document in isolation intentionally does _not_ have a single correct display. _Any_ display driven by a consistent transformation from the XML source is in some sense a sensible view _for some application._ >>developers would like. Leaving this behavior up to the application is >>probably the only course available at present, but I suspect this practice >may >>lead to considerable chaos. > >See the idealistic ideas above :-) Without a formatting specification you can't display an XML document "interoperably". With such a specification, it's a relatively simple matter of program correctness to determine whether you have or not. >Yup - it has revolutionised my thinking. It means I can through away 50% of >my code because there are general solutions. XML-LINK EXTENDED is even more >fun. I shall have some proposals there :-) I'm glad to hear this. None of the problems you are mentioning are insignificant, but they are almost all problems for XSL, and _not_ XML itself. -- David _________________________________________ 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...) 
|
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
|
|||||||||
