[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: EMBED and validation

  • From: Peter Murray-Rust <peter@u...>
  • To: "Simon St.Laurent" <SimonStL@c...>, "Xml-Dev (E-mail)" <xml-dev@i...>
  • Date: Thu, 27 Nov 1997 09:08:53

embed validate
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.