EMBED and validation

[Simon St.Laurent]

>It's a quotation. One thing you could do is put an embedded scrollable
>window in the linking document, so that he reader sould read the entire
>linked-to document in context.

Yes, it is effectively a quotation.  Long quotations, however, often have more 
structure and require more formatting than a short quotation in a print 
document, and I would like somehow to preserve that structure.  Providing an 
embedded scrollable window is a good idea for things you COULD do, but is not 
something that can be counted on.  We don't plan to create applications 
specific to this document set at present; though we may do so in the future, 
this document set would still be likely to cross into foreign applications.

>Asd with most generic markup, how it is to be displayed or processed is
>something that information providers and users must be free to change as
>supporting technology and the use of the document evolve.

While freedom to change is certainly valuable, freedom to work consistently 
with a variety of applications is of considerably more importance on this 
project.  Communicating more clearly the way in which these documents should 
be treated by applications appears to be a necessity, as XML itself appears to 
provide no such support, nor does it sound like the readership of this list 
(with a few exceptions, of course) is particularly interested in providing 
such support at this time.

>However, there's nothing to prevent a resonable formatting
>script from being provided as part of the format specifiation for the
>linking document that can properly format the EMBEDed data.

Formatting script?  I think we were hoping to use something more in the order 
of CSS or eventually XSL.  While XSL will  provide scripting capabilities, it 
seems like we're piling on additional complexity and new problems for 
applications.  Though I haven't tried it yet, it seems like it will be an odd 
challenge to create a specification for the linking document that will contain 
styles for linked information that isn't included as part of the parser tree 
for the linking document, particularly if the type of information to be linked 
isn't known at the time the styles for the linking document are established.  
It can be done; I just don't look forward to it.

>if you are providing such documents as part of a publication process, you
>are well-served by providing stylesheets that will format the link _as you
>want_. if you are creating some form of repository, you need to document
>the intended meaning of such links so that future creators of presentation
>and interaction specifications can provide appropriate implementations for
>them.

What I would like to be able to do is provide stylesheets and documentation 
that can be understood by a variety of processing applications that will work 
in a consistent manner with linked material.  The paragraph above describes 
quite neatly what I want; the rest of this conversation, however, has 
indicated that you can't get there from here.

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

Radical?  Radically practical, or so I thought.  I'm hardly saying that 
developers _should_ obey this, or that application developers should implement 
a limited processing model.  Being conservative in this instance means 
accepting a reasonably loose set of rules designed to make certain that 
documents can still be processed in a wide variety of application processing 
contexts.  As I'm developing document sets here, and not applications per se, 
I'm not sure this ad-hoc constraint is anything but a simple concession to the 
vagaries of the standard.

I had hoped the standard would be clearer on these issues, but the wide 
latitude given applications will have a dramatic, though not especially 
painful, impact on this document set and others I may create.  Paul Prescod 
pointed out that yes, of course, applications CAN follow several of the models 
I proposed, but that this behavior cannot be counted upon.  CAN is not good 
enough in many situations, so I'll develop the document set so that it WILL 
work regardless of the processing model applied. Seems simple enough, though 
it requires some extra effort.

Sooner or later I'll write some applications, and maybe I'll be able to take 
advantage of the freedom given application developers.  In the meantime, I'll 
explore the constraints set upon document developers that are imposed by that 
freedom.  The discipline will probably produce better DTDs and documents 
anyway.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer (January) / Cookies (February)



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)