EMBED and validation

[Peter Murray-Rust]

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 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)