Fw: XLink: behavior must go!

[Oren Ben-Kiki]

The Xlink thread is fascinating because it is a concrete manifestation of an
abstract issue dealt in other threads (e.g. the OO/scripting thread). Viewed
this way, I think the argument tends to Paul's side. XML is not a
programming language; it is a data language. The "behavior" attribute
doesn't sit well in a data language.

Paul's alternative - allow attaching arbitrary attributes to an XLink, with
application specific semantics - makes much more sense. Given the semantics
of "behavior" is already application specific, why insist on a fixed name?
This is only a way to ensure namespace problems. Much better to have
"myapp:behavior"; this way you know the exact semantics of the attribute
with no ambiguity, or know that you can't parse this specific attribute.

Martin Bryan <mtbryan at sgml.u-net.com> wrote:
>Paul Prescod wrote:
>>You and I agree that various document types have differnet behavioral
>>needs. We agree that there is no way that we can define everything that
>>needs to be done in advance. I think that we agree that usually behavior
>>should be defined in stylesheets, though there are a few cases where it
>>should be defined inline.


Well, at least I agree :-)

>Not my words. I think that there are times when you want to be able to
>contol the behaviour inline, not define the behaviour inline. I want to
>provide a declarative property, not a procedural one.


Any attempt to "control the behavior inline" means "give an algorithm fot
handling this link" and while this may be done decleratively, it is way out
of scope for XML.

>>You demand that when it is inline it should
>>always be expressed in the same attribute. I claim that this will
>>interfere with the goal of extensibility and interoperability.

>
>Only if we have a common attribute will we be able to share processing
>modules among applications. My goal is to be able to have processing
modules
>that I can import into any XSL stylesheet that processes a document using
>XLinks to allow me to link from the request for data to my local (or
>external) databases, undertaking appropriate transformations to turn the
>data stored in the warehouse into the form that the author of the document
>wants it.


Here's the core of the problem. XML is trying to hold a very long stick at
both ends. On the one hand, we want to be able to define domain-specific tag
sets and attributes; on the other hand we want universal clients to process
them. Something has to give.

The current solution is to require clients to process a well-know small set
of standard XML languages (e.g., XSL FOs), and have someone provide an XSLT
"stylesheet" (horrible name) to convert the input document into one of them.
This allows XML itself to be domain-neutral, and still allow for universal
clients. So far so good.

What Martin is pushing for is making the "stylesheet" itself - or at least
parts of it - universal. This is a misguided goal IMVHO. It is on par to
requiring standard XML elements for "author", "title", "version", ... to
ease document retreival. The way I see it, if XML is to define any form of
predefined elements or attributes these had better be elements or attributes
which are useful and _have the same semantics_ for each possible
application. Otherwise, don't bother.

>While I can introduce your suggested martin:behaviour attributes into my
DTD
>I cannot introduce them into someone elses DTD.

Actually, someone else can refer to your "martin:behavior" attribute in his
DTD (well, assuming namespace enabled DTDs but that's a separate issue).
People could set standards for such attributes in particular domains - for
example, "browser:behavior" as opposed to "vlsi:behavior" or
"publishing:behavior" - assuming 'browser', 'vlsi' and 'publishing' refer to
appropriate URIs, of course. Note I'm not enthused by "javascript:behavior",
since it is inconsistent with the XML-as-data-language view.

>If I am using an industry
>standard DTD that uses XLinks how can I control standardized processes that
>are known to work in my environment


No, 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. Having a fixed
name would only make the life of the stylesheet writer that much more
difficult - if not downright impossible.

>Saying I should just change stylesheets does not necessarily work as it
>depends on where control of stylesheet association takes place. At present
>we have not mechanism for local overrides of stylesheets. What I want is a
>mechanism that will allow me to control the working of imported sytlesheet
>modules on an instance by instance basis, without having to write special
>instances of stylesheets for each document instance.


That's a valid concern, but it has little to do with the XLink proposal and
the behavior attribute. Here CSS has an advantage over XSLT - it is much
easier to provide overrides in CSS then it is in XSLT. Of course, if you are
a member of the XML -> XSLT -> XML + CSS camp, then there's your (partial)
solution...

<Note>
The way I see it, the code vs. data debate hasn't been settled yet. The
current accepted technology, HTML, is a hybrid of both and therefore nobody
likes it. XML is on the pure data side, but its success is yet to be seen.
Java is on the code's side, and its success is also not clear (the Jini
project, for example, demonstrates what this approach can achieve if
seriously adopted).

The ultimate test of both approaches is trying to use a document/object in a
system it wasn't designed for. After all, there's no such thing as a
"universal: client - it either displays on the screen, or activates
speakers, or prints, or modifies databases, or something.

The code approach is less suitable for adapting to unexpected applications.
Given a pieces of java code which draws on the screen, it is very difficult
to convert it to code reading text on the speakers or writing to a database
record - unless it was designed with that in mind in the first place, of
course.

But the data approach is only slightly better; it keeps the data the same,
but needs a new stylesheet per each application (for example, one for
viewing on the screen and one for playing over speakers). How likely is it
that people will bother to provide an aural stylesheet for their XML
language?

The best solution is to define standard languages/interfaces allowing the
same data/code to be shared across applications. This works equally well for
both approaches, but is very difficult to do. Hitting the right level of
abstraction for combining domains (e.g., display and speech) is very
difficult (hint: FOs are not the right level :-). Again, the data approach
has a slight advantage here - since one only needs to specify the "data" and
not the "behavior" specific to the application, it already starts more
general.

Which brings us back to why "behavior" must go :-)
</Note>

Share & Enjoy,

    Oren Ben-Kiki


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)