Lists Home |
Date Index |
- From: Peter Murray-Rust <firstname.lastname@example.org>
- To: "Simon St.Laurent" <SimonStL@classic.msn.com>, "Xml-Dev (E-mail)" <email@example.com>
- Date: Thu, 27 Nov 1997 09:08:53
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.
>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 -
>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
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
- 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
- the whole 'document' in which the link occurs (this emulates <A HREF> in
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
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.
<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:
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.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)