XLink: behavior must go!

[Martin Bryan]

Oren Ben-Kiki wrote:
>you can use an industry-standard DTD to good effect - it is just that
the industry in question isn't "the XML industry"; instead it might be "the
XML browsing industry", and the standard isn't "XML", it is "XML as used in
browsers". There's simply no way a browser will be able to correctly handle
links whose behavior is specific to vlsi design process, unless someone
explicitly codes a stylesheet which explains how to do so.

The problem I am trying to deal with is not related to "the XML industry" or
"the XML browser industry" - instead it relates to a set of DTDs that share
common-features which apply to a wide range of applications shared by a wide
range of industries. If we are to develop sharable toolsets we need to
develop sharable architectures. The key point is that I want, in the longer
term, to replace the current practice of relentlessly copying data from one
message to another (up to 10 times in some processes) with a process that
allows linking to the original source of the data. The way this will be done
will depend on the type of the data being linked to and on the local
conditions for access to original documents. OK, I can define a generalized
architecture that would be widely used for this purpose, and call it
edi:behaviour, but as this is widely required by others why not also have it
as a standard mechanism for passing link instance dependent information to
the link processor? It should not be necessary to have individual
stylesheets for individual instances of messages. It should not be necessary
to redefine processes for each DTD that uses the shared information. We need
to import standardized modules that will process standardized namespaces of
elements in ways that depend on the conditions applying at the point at
which the located data is to be retrieved from.

Paul Prescod wrote:

>So you want the features of the whole grove model and API and you think
that a single standardized attribute name is going to give it to you?

I have given up hope of getting an extensible grove model (note the key word
at the beginning) or a proper API for managing the associations between XSLT
and XML document instances (note that it is the instance I worry about, not
its formal model). This is why I want to introduce, as a stop gap, a single
architectural form that will apply to one class of objects in which I know
from experience there is a particular problem. I would dearly love a better
thought-out, long term solution based on proper architectural form
definition, but in the meantime need to retain the stop-gap attribute to
manage link processing. Don't throw out the bathwater until you know you
have something to give the baby to drink. [They have just announced that
they have cut the water supply to my house, which made me think of this
variant of the metaphor!]

Martin Bryan



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/ and on CD-ROM/ISBN 981-02-3594-1
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)