Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: EMBED and validation
 At 05:09 28/11/97 UT, Simon St.Laurent wrote: >>No; it's not part of the document; it's a hyperlink to something >>completely different; there's no reason to expect what it points at >>to be XML. -Tim No - and JUMBO can eat about 17 types of non-XML files (e.g. *.txt, *.gif, and lots of lovely chemistry). If *any of you* want to write a simple routine for RTF, Word binary, MAC BinHex, it would be marvellous. All you need to do is decide on the tree structure - JUMBO can then output it in shining XML. > >While there is no reason to expect the target to be XML (which I strongly >approve of), I have to wonder what's supposed to happen if the target _is_ 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... >XML. If the target is another complete XML document, including a document >type declaration, then I can see the wisdom of parsing it separately and >keeping it separate. If the target is XML but not a complete document, for >instance a set of elements returned by a reference using XPointers, I'm not This is (I believe) 'application-dependent. I see the following possibilities. (A) Render the tree and paint the referred elements blue. JUMBO does this. You don't get a choice of colours at present (B) Render the event stream and paint the elements red. JUMBO cannot do joined up writing yet, but is gradually learning how to render event streams (it can do most of HTML 2.0) (B) Regard this as a query (remember our discussions here?) and use the nodes in some other way. That's why I think XLL Xpointer syntax is the appropriate base for a query language. >sure about what the application should do. 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. The question is ACUTATE="AUTO" SHOW="EMBED". There are several options. A. treat it as a separate object (possibly a BLOB like a gif), work out how big it is (pixel wise), create a pretty box and render it in there . JUMBO started to do this, but got lost in flowObjects. Now I think it would do better. But you need to be able to handle flowObjects in your metaphor. B. parse it as a tree and replace the XML-LINK node. This would then look very similar to &foo;. The advantages are that the target can use a different DTD (although writing out the combined tree could be hairy). One disadvantage is we need a switch to do this, which is why I proposed XDEV:INCLUDE. A more serious disadvantage is that recursive following of EMBED/AUTO could give rise to all sorts of fun things, like cyclic recursion, getting into hairy areas, actuating buttons on nuclear power stations and so on. C. render it as a thumbnail and get the user to click it In many ways EMBED/AUTO can do everything that &foo; does and (as far as I can see) everything that NOTATION does. The attraction is that it can be further customised through attributes. &foo; cannot refer to non-XML objects, NOTATION seems to have an additional level of indirection and I don't understand it yet, since I've never seen it used. >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. >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 :-) >situations will arise in which EMBEDded content needs to be styled, but the >chunk of XML referenced by the link contains neither document type declaration >or styling information. 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. > >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 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 :-) >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 :-) > >XML-Link has opened up realms of capability that go far beyond those provided >by entities and notations, and I look forward to using them. 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 :-) P. > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg 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
|
|||||||||
