Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "David G. Durand" <firstname.lastname@example.org>, "Xml-Dev (E-mail)" <email@example.com>
- Date: Sat, 29 Nov 97 06:14:34 UT
>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
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
Dynamic HTML: A Primer / XML: A Primer (January) / Cookies (February)
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)