Re: XLink: behavior must go!

[Rick Geimer <rick.geimer@xxxxxxx>]

While I agree in principle with the notion that it is generally a bad idea to
create markup that specifies a behavior, there are many real world examples
where this is the only practical thing to do. I will use as an example the
exchange standard for the Semiconductor industry, ECIX (formerly known a
Pinnacles, or PCIS).

>From 10,000 feet, the standard specifies that semiconductor data should be
stored in a non-visible database-like section of an instance, then that data
can be reflected into the viewable part of the document for display online or
for printing. This allows the data to be easily processed by a machine or read
by a person.

For this to work, the standard had to specify a <reflection> element with a
predefined behavior, i.e. take the contents of the element who's id matches
the reflection's idref and redisplay it inline at the location of the
reflection element...the same idea as show="embed" and actuate="auto", if I
understand XLINK correctly.

I don't think it would be appropriate for a standard to mandate a particular
stylesheet language along with the markup to make this work (though the only
way I have been able to get this to work with any XML tools today is with
XSL). One could argue that there are ways to make this work using entities
(which would get really unruly after the first few hundred) or some other
tricks, but in the end this would just be beating around the bush. This
particular application needs to define a certain amout of link behavior to
achive it's goal...database-like structure with human readibility. If this
kind of link behavior can be specified in a standard way with XLINK, all the
better.

Rick Geimer
National Semiconductor
rick.geimer@xxxxxxx


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list