xml-dev - RE: EMBED and validation

[dgd@cs.bu.edu (David G. Durand)]

At 9:16 AM -0000 11/28/97, Peter Murray-Rust wrote:
>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...

That's what NOTATION is for. Use an external entity, and makes its notation
be the MIME type of the content, and then you're all set.

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

This is all a question for the stylesheet/processing langagues, and not for
XML per se.

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

not strictly correct. the stylesheet processing is application dependent.
The validation is _not allowed_ as part of XML validation. You can of
course require that your application limit the valid XML documents that it
will process, but then you are limiting the documents that it will process,
which may not be a good idea.

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

Styling yes, validation no.

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

For an XML document, you can refer to the whole document and use extended
pointers to pick out the linked sub-part -- this lets you get DTD, and
content-type (via NOTATION).

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

This is not consevative, but radical, sit it imposes an ad-hoc constrain on
linking, based on a limited processing model.

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

No, interoperable in the sense you mean (interoperable without a
particualar stylesheet to interpret against) is in fact a gigantic mistake
that XML is designed to help peopole avoid. The point of XML is to separate
rendering and other processing from document representation and semantics.
This means that no viewer can process an XMl document for display wothout a
separate specification of what display is desired. It will be possible to
test application compatibility when applications take XSL document + XML
document pairs. An XML document in isolation intentionally does _not_ have
a single correct display. _Any_ display driven by a consistent
transformation from the XML source is in some sense a sensible view _for
some application._

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

Without a formatting specification you can't display an XML document
"interoperably". With such a specification, it's a relatively simple matter
of program correctness to determine whether you have or not.

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

I'm glad to hear this. None of the problems you are mentioning are
insignificant, but they are almost all problems for XSL, and _not_ XML
itself.

  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)