[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XLink comment and queries

• From: "W. Eliot Kimber" <eliot@i...>
• To: xml-dev@i...
• Date: Thu, 23 Apr 1998 13:54:13 -0500

At 02:11 PM 4/23/98 -0400, Daniel Pitti wrote:

>Thus, in trying to XMLize an existing SGML DTD, I find myself wanting my
>linking elements to have both idref/s and entity/ies for use in creation
>and maintenance, and XLink attributes for exporting the same, the latter be
>created at the time of exporting. Is this sensible at this juncture? Or am
>I overlooking something?

My standard advice in this type of situation is as follows:

1. Plan to always have a "publish" step from your authoring/archiving
repository to the outside world. 

2. As part of the publishing process, plan to do whatever transforms are
necessary to make your information usable by its recipients. Even if today
it's an identity transform or just SX or SGMLNORM, you should put it place
so you have a well-defined process step you can expand later.

3. Come to understand that the form of addressing used in any situation is
determined entirely by the practical considerations in the use scenario and
should have *nothing* do with the rhetorical or presentational semantic of
the element.  Addressing is plumbing and, while of keen interest plumbers,
the form of pipe used does not normally affect the "meaning" of the house.
You can change from copper to PVC pipes without affecting the relationships
among the rooms in your house.

One key implication of these three recommendations is that the form of
addressing used in a document at any given time will be determined by the
requirements of its use context and *is subject to change*.  In other
words, the form of addressing use over the life of a document will very
likely change. Your DTDs and management systems should expect that.

For example, during authoring you want a very flexible, easy-to-manage
addressing method, so you will probably do something like use queries
unique to your repository, repository-wide unique IDs, HyTime-style
indirect addressing, etc. XPointers are not, with a few exceptions,
appropriate during authoring because they are too direct. In particular,
they bind the specification of the ultimate target too close to the initial
reference, which always impairs managability (one reason that HyTime
started with completely indirect addressing).  Thus, you are unlikely to
decide to use XPointers during authoring.

But, XPointers are very well suited to delivery of static (or mostly
static) documents. In particular, because they are very direct, they are
easy to implement and resolve. Thus, you are likely to decide to use
XPointers for delivery of information out of your respository.

This suggests two things:

1. Your DTD should enable the use of a variety of addressing methods. The
HyTime standard provides syntax that lets you declare in a DTD or instance
what forms of address are being used. [I'll post a separate note with an
example.]

2. You should plan to do an address transform as part of your publishing
process, transforming the forms of address used for authoring and archiving
to the forms used for delivery (which may vary based on the expected
recipient).

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: help me understand DOM XML Level 1
• Next by Date: Re: Semantics (was Re: Inheritance in XML [^*])
• Previous by thread: XLink comment and queries
• Next by thread: Re: XLink comment and queries
• Index(es):
  • Date
  • Thread