EMBED and validation

[David G. Durand]

On Dec 1,  3:36pm, Simon St.Laurent wrote:
> Subject: RE: EMBED and validation
> >From a DOM perspective, EMBEDded material will almost certainly not be
> >considered part of the document tree containing the EMBED element.
>
> I very much look forward to seeing what the DOM does (or doesn't do) with the
> EMBEDded material.  But is this an issue for the DOM in particular, or should
> the XML-Link spec give clearer direction about the nature of EMBEDded
> material?  Especially as some of the replies so far have said that an
> application _could_ include the EMBEDded material in the document tree _if_
> the developer so chose - which opens the door to multiple interpretations in
a
> large way.

You're getting closer. The document, itself, contains no embedded material: it
contains an "EMBED" (quitation) link to other material. It will not be a
requirement for any XML application to do anything other than include the XLL
attributes in it output for applications that want them. This attribute
information is part of the proper domain of the DOM, as I can understand it.

XLL applications will be required to interpret the link as a _connection_
between two points, with "default semantics" of "include as quotation". Whether
than is most convenietly implemented boy combing document data structures, as
you and Peter assume, or by some other method that preserves two structures,
and renders them in a particular style is an application implementation
decision.

Regardless of that implementation strategy, XSL stylesheets for XLL constructs,
will have to specify how to choose display options for such links. Those
construct _will_ have to deal with the fact that XLL links _need not_ be to
"well-formed subtrees" of the linked-to document. This is of critical
inportance for implementing external markup and arbitrary quotation. So, any
implementations strategy that depends on WFST (Well Formed SubTrees) will fail
for some legal imnput documents. That's fine, depending on the goals and
limitations of the application.

   It is concievable that XSL will not give any method for formatting non-WFST
EMBED links. That would also be OK, as people who require the more complex
linking can still create their own (more complex) applications.

However, purely in the form that you've asked the question (i.e. XML parsing
rules), there is no inherent relation between EMBED linking and document
validation -- and this is not an oversight, but a planned strategyu to enhance
the reusability of hyperdocuments in the same way that XML enhances the
reusability of single documents -- by late-binding all formatting and display
issues via a stylesheet or toerh form of processing specification.

The confusion over "application flexibility" is occuring because people are
used to early-binding models like HTML, where the format of documents is
explicitly encoded in the document. To judge application compatibility you
require not only the knowledge of the XML input, but the stylesheet language
(processing model) being apllied to the document.

I've seen nothing so far in the XDEV proposals that is not more properly an
issue for XSL.

One way to see that this flexibility is required to is to imagine in what sense
there can be interoperability between a web-mapping, or web-indexing
application and a browser display application. They might have very different
strategies for when to do many things (such as expand entities) and attach very
different semantics to those operations (a map might represent entities as a
special type of link, a browser would silently expand them, or perhaps use a
stretchtext view where the entities were buttons that would trigger textual
expansion when clicked). Formatters would selsect such options based on their
stylesheets. Analysis application might more often do the same thing via
hard-wired code or configuration files.

> And, of course, I can think of a considerable number of applications where it
> might be useful to be apply to apply the DOM to EMBEDded content without
> having to cope with a separate document tree.

That is fine, but that is a decision on processing model that, if taken, will
not handle certain legal XLL-linked documents... You can pick your processing
model, but then you have to live with the consequences.

> Sounds like fun.  For the applications I'm proposing, I'd like them in the
> document tree, but of course that isn't appropriate for many situations.  I'd
> really rather not see this prohibited, either - it would chop off an entire
> branch of XML development I'm working on.  Could be the price of progress.
> We'll see.

I think the price will be some options in XSL (entity expansion rules) that may
seem mysterious at first and second glance, but will enable much more
sophisticated (and controllable) hypertext interaction.


> I guess what I'd love to see is another XML-Link attribute specifying whether
> to include an EMBED in the document tree or not - it seems to be the central
> issue around which this discussion has focused. Failing that, I'll look into
> Peter's proposals for XDEV, since they seem to address the challenges of
> multiple application behaviors directly - if they get implemented by
> application developers, of course.

This is:

  1. not XLL's job, as explained above. Whether a processing models includes
the tree is relevant only to that processing model, not the document itself.

  2. That attribute would only be legal for the subset of XLL links that select
WFSTs of the destination document -- this is an unreasonable limitation that
removes some useful applications of such links. For an interesting example of
the scholarly use of such markup, the MULTEXT project may be of interest (
http://www.cogsci.ed.ac.uk/~ht/nsldoc/nsldoc.html ).

  3. If 2 is deemed a minority view, XSL will support _only_ what you ware
requresting, but other processing languages will be able to process such
linking structures.



------------------------------------------+----------------------------
David Durand                 dgd at cs.bu.edu| david at dynamicDiagrams.com
Boston University Computer Science        | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/  | http://dynamicDiagrams.com



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)