EMBED and validation

[Peter Murray-Rust]

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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)