|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: EMBED and validation
At 02:13 27/11/97 UT, Simon St.Laurent wrote: >This may be obvious, but I can't find it in the spec. No - it's not obvious and - yes, it isn't in the spec. Deliberately, I think. > >In XML-Link, does XML content that is included by EMBED in a valid document >have to go through validation like the other parts of the document? Is >EMBEDded content considered part of the document for styling purposes, grove >manipulation, etc.? This could potentially have an enormous impact on two >DTDs I'm developing. At present, the material I would like to embed will >validate anyway, but it may not always be the case in the future. Information >embedded after the document has loaded appears to create an entirely new set >of parsing and styling problems, but hopefully there's an answer already - the >tool is too good to pass up. When XML-LINK came out I asked (probably to the point of boredom) what the semantics associated with XML-LINK are. The answer (I hope I'm being fair) is that its completely application-dependent. In particular this applies to the word 'EMBED'. If, as I believe, the spec will stay in its very crisp and semantic-free form, then I believe it is critical for the XML community to get at least some communal consensus on XML-LINK semantics or I think we shall have serious interoperability problems. That's only *my* view - others seem either more relaxed, or seem to think it's a totally insoluble problem. That is why I have suggested that we use XDEV as a way of at least identifying different approaches. I believe that the motivation for AUTO + EMBED was to replicate the <IMG SRC=foo> construct in HTML (USER+REPLACE corresponds to <A HREF=foo> so long as replace is the whole 'resource' (again I have asked repeatedly for clarification as to what a 'resource' is.) A 'resource' seems to be (according to different authorities) : - a nodes in trees (Eliot Kimber on XML-DEV) - the content of the linking element (e.g. the content of <A HREF>...</A> - the whole containing element (i.e. as above but including the <A> and </A> tags - the whole 'document' in which the link occurs (this emulates <A HREF> in HTML). There seems to be no concern or urgency to clarify this further to webhackers like me, so perhaps I am the only one who sees a problem :-) *What* embed *does* is even less talked about and defined by the experts. It is clearly seen as being able to support <IMG SRC like behaviour, but what if the document is not primarily textual. How does one include something in a tree? I have also asked about whether <FOO ACTUATE="AUTO" SHOW="EMBED"> has any semantics suggesting that the document linked to should become part of the current document (I hope you understand what I mean :-). In this way linked-to 'resources' could become 'included' or 'transcluded' in the current document. JUMBO has the capability of doing this, though I haven't switched it on because I wanted someone other than me to come up with ideas. Example: <P>The equation for exponential growth is<BR/> <ITEM SHOW="EMBED" ACTUATE="AUTO" HREF="eqn1.xml"> and its first derivative is identical</P> would link to an equation in MathML. The advantage is that your document could use a different DTD from MathML. Whether you process the MathML document on linking to it is 'application-dependent'. What happens if *it* points to further documents is most exciting and most certainly undefined. Note that XML-LINK need not link to an XML document. It could link to a *.gif, or (as in the latest version of JUMBO) to *.txt and *.mol (molecules). In this way object can sometimes be converted on the fly into XML trees, and could - if required - be display and treated (e.g. for searching) as part of the document. I have proposed that a MIME attribute be added to the XML-LINK repertoire. IMO this is more powerful that entities because one can mix different DTDs, but it's also more complex. Even entities have undefined areas as I pick up that some parsers may allow expansion of entities or not at user control. Some SGML experts may respond and say that NOTATION will manage this. I have to admit that I don't understand NOTATION. It seems to have implied semantics of linking to an entity. IMO XML-LINK can do everything I need and I don't required NOTATION. It will be a lot of work if I have to hack JUMBO to use NOTATION and no-one uses it. QUESTION: does anyone actually intend to use NOTATION in XML-LINK? If so, what for, and where is the software coming from? :-) So - I suggest that in XML-DEV we try to agree on sets (not a set) of semantics that can be used with XML-LINK. I know that most people think I'm mad to suggest this, but I *have* had some private support for the XDEV idea. Therefore let us suggest: (ignore capitalisation) The BEHAVIOR value can be chosen from a list of value of the form XDEV:* (and of course 'application-dependent' values :-) Their semantics are determined by referring to postings on this list. Let's kick off with: XDEV:DISPLAY "a graphical or textual rendering of the object" XDEV:DISPLAY_IN_CONTEXT "a graphical or textual rendering as part of another element or resource" (See PeterMR earlier on XML-DEV) XDEV:INCLUDE "make the linked-to resource part of the current tree/document" XDEV:INCLUDE_RECURSIVELY "make the linked-to resource and its child links part of the current document" and include another attribute: XDEV:MIME which can have values consistent with (whatever the MIME RFC is). These are just starters. please refine them, but please also keep them simpler that HyTime. I am sure the HyTime experts are planning to build HyTime on top of XML anyway, so if you want a full hypermedia system no doubt it will arrive sometime. I suggest we keep this very simple, with the main objective being to avoid inconsistent semantics if possible. 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
|
|||||||||

Cart








