Lists Home |
Date Index |
- From: firstname.lastname@example.org (David G. Durand)
- To: "Xml-Dev (E-mail)" <email@example.com>
- Date: Fri, 28 Nov 1997 15:31:28 -0500 (EST)
At 5:09 AM -0000 11/28/97, Simon St.Laurent wrote:
>While there is no reason to expect the target to be XML (which I strongly
>approve of), I have to wonder what's supposed to happen if the target _is_
>XML. If the target is another complete XML document, including a document
>type declaration, then I can see the wisdom of parsing it separately and
>keeping it separate. If the target is XML but not a complete document, for
>instance a set of elements returned by a reference using XPointers, I'm not
>sure about what the application should do.
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.
Or you might want to format it inline as a "long quote" or something. or
you might want to simply note that a citation was made in the form of a
quote of a particular region of the linked-to document as part of a
The Link records a relationship between a document and a portion of a
another document. I think the term EMBED is fr from ideal because it
encourages an operational definition that is not always appropriate
(thought it is probably the proper definition for simple browsing apps).
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.
>Is the application supposed to treat this chunk as (hopefully) well-formed
>in a separate parsing process?
If that makes sense.
>Would it be legitimate for an application to
>fold EMBEDded chunks into the document containing the link for purposes of
>styling in particular but also validation in certain circumstances?
Not for XML validation, ever, because XML validation is only done according
to the rules in the XML standard. Your application and DTDs might require
such an extra kind of validation, although I think that this would be a
very bad decision for a general-purpose XML processor since that
requirement will _not_ be hinired by many documents.
Obviously, inline formatting is a reason for the processing hint intended
by the word IMBED in the first place.
>situations will arise in which EMBEDded content needs to be styled, but the
>chunk of XML referenced by the link contains neither document type
>or styling information.
To the extent this is done, such documents may be hard to process with soem
applicaitions. 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. In fact, that
would probably be a requirement for providing such documents to browsers.
>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
>developers would like. Leaving this behavior up to the application is
>probably the only course available at present, but I suspect this practice
>lead to considerable chaos.
It will only lead to chaos if people assume that an application is
responsible for figuring out what to do in such cases.
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
>XML-Link has opened up realms of capability that go far beyond those provided
>by entities and notations, and I look forward to using them.
Definitely. One thing that takes a while to get used to is the
"declarative" way of thinking require to make effective use of XML and
content markup generally. Then, once you've done that, you need to apply
the same abstractions to hypertext structures: a link is not just shorthand
for a particular interaction behavior, but a description of a relationship
between document portions that might be displayed, analzed, or otherwise
used in many different ways.
This was common wisdom in the hypertext community, but is having to be
rediscovered on the Web. (It's particularly ironic, since Tim Berners-Lee
understood this from the beginning, even though he didn't invent it).
David Durand firstname.lastname@example.org \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)