xml-dev - RE: EMBED and validation

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

At 6:14 AM -0000 11/29/97, Simon St.Laurent wrote:
>>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.

I also listed several other things you could do with the link, such as
formatting it inline. My point was that the _presentation_ of the linked
data is a matter for the application and/or stylesheet -- not the XML
document. Do stylesheets need to be able to process such stuff -- yes, that
was the point I was trying to make.

I chose the nested window as a main example because I think it's a good
idea that is _not_ supported by current software, but that could be enabled
by the this type of link. And it's a grewatr example of how you could
instantly take your old-fashoned "long quotes" and turn them into
"Browsers, Inc's Web-o-Namic Nested Dcouments (tm)" without changing your
markup at all.

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

No, you need to make an appropriate decision about stylesheets if you are
providing documents. Any requirements that you have for XSL would be well
made public, as input to that standardization process, now underway. If you
will be delivering your documents before the stylesheet work is complete
you will have to work with prerelease software or roll your own, or use CSS
or compile to HTML, or something else. The lack of such presentational
details in XML itself is still a good thing. You are free to create content
today that will work with XSL -- even when XSL does not exist yet -- and
can design your own processor if you need to. On the other hand if you
invent a bunch of "conventions" that import presentation details into your
documents you will simply be doing work that you will at best have to throw
away, and that at worst may lead to bad encodings of your document
semantics and send you back to square one to re-markup your documents.

XML is the content part of the equation, and that's what it's for. XSL and
its possible competitors (there _will be competitors_, because formatting
is a place the people will want to compete) will be the way to realize the
presentations you prefer (whatever they are) using the same
technology-independent source files.

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

I used the term script to emphasize that any programmatic trasnformation
for viewing is usable -- some people have been confused by my use of the
term stylesheets for link-rendering, so I've tried to avoid using _only_
that term. Sorry for the confusion. CSS or XSL are _exactly_ where this
whole problem belongs.

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

No, it's indicated that without stylesheets or some other programmatic
process, you can't get there. This is not a big surprise, as that's the
point of content markup. Yes, stylesheets are going to have to handle
links. In some cases you may have to write scripts to perform interactions
you want, and embed them into stylesheets. That's just part of the work of
document delivery.

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

If you're just talking about a rule that you want to adopt as part of your
authoring process, there's no problem. You posed a question about software,
and so I answered in terms of how the software should work. If you're a
document provider, you will need to specify how to format linked material
if you want it formatted inline. If you want it to just show up
pre-scrolled in another window, I expect that XSL will have  away to do
that -- then you'll lose some context, but gain by having simpler
stylesheets. This is a tradeoff that is independent of linking strategy. If
you intend to use inline formatting, and are writing the stylesheets as
well as the documents, such a discipline may well make your documents
cleaner, and your stylesheets simpler

The question is what these presentation details have to do with XML?

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

Paul is right, but applications that purport to implement XSL, however,
will not have so much latitude when the are processing a document according
to a stylesheet. In fact, they will be constrained by the XSL standard in
exactly what liberties may be taken.

So I think you're worrying about a non-problem, as long as you will be
providing stylesheets for your documents.

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

I don't really know what this last means, but certainly we all look forward
to imporved and richer displays once the semantics of documents and the
format for displaying them can be separated.

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