XLink: behavior must go!

[Oren Ben-Kiki]

Martin Bryan <mtbryan at sgml.u-net.com> wrote:

>I wrote:
>
>>If you can define a set of behaviors and make a good case that this set is
>applicable to the vast majority of XML applications, they I'll gladly join
>you in lobbying for adding an 'xml:behavior' attribute to XLink with this
>set of values. In fact, I'm all for releasing XLink without a behavior
>attribute and creating a WG (or maybe placing it within the XLink WG
>mandate, whetever) dedicated to this attribute.
>
>I do not believe that we are yet in a position to predefine the behaviours.
>These must be specified by particular industry groups, not by W3C.

That's also my position.

>Suggestions like <MYLINK ... BEHAVIOR="popup()">  (made by Paul Prescod)
are
>not what I had in mind - behaviour should not point to a procedure it
should
>either pass parameters that can be used by procedures, e.g <MYLINK ...
>BEHAVIOR="popup"> or better still, like namespace declarations, point to
the
>source of the definition of the behaviour, e.g. <MYLOCATOR...
>BEHAVIOR="http://www.healthcare.org/xml/behaviours/popup_menu.xsl">.

We are agreed on that as well. The question is, what is the best way to
ensure this? We have several alternatives:

1. Leave 'behavior' unspecified and rely on people's common sense.
2. Make it a requirement that values to 'behavior' must be URIs.
3. Use XML namespace mechanism instead to qualify the attribute name,
instead of its values.

The spec now uses option (1), which I think is unsatisfactory. Let us at
least have an editorial note recommending URI values! Paul (I presume) and
myself would rather have option (3), as being more in tune with other XML
standards (namespaces). But (2) also gets the job done. Given that (2)
requires a very minor change to the spec as it stands (just adding a
sentence or two), I guess it is the most practical one. If that's what it
takes to get the spec out the door, so be it.

>Now to come to another point Ben made in response to my comments that:
>>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.


Urr... My first name is 'Oren' and the last one is 'Ben-Kiki'. 'Ben' is sort
of a prefix (son-of) in Hebrew, but is a seperate word. Never fails to
confuse English speakers used to middle names :-)

Anyway, I said:
>>Agreed; why do these follow from what Paul (and I) propose?


>I don't think they follow from what you have been saying, but they are
>something that has not been adequately thought through in the overall model
>of the XML family. Ben rightly suggested that we should used DTD fragments
>to define shareable resources. But how do you link sharable DTD fragments
to
>sharable stylesheet fragments? How do you link stylesheets to local
>processes in a way that allow the local processes to be used with many
>different stylesheets, whenever a particular DTD fragment is invoked, and
>how do you provide user control over processes that are handled in multiple
>places. Remember that a multiheaded link is likely to be pointing to
>resources based on different servers, using different local processes to
>undertake business-related procedures that necessarily must be handled
>outside the stylesheet.


Good questions! If I knew the answers, I'd probably be a W3C WG member
instead of an outside kibitzer :-) BTW, I agree that these questions weren't
thought completely through; however the WGs did invest time and effort in
these directions - wo do have namespaces, for example. I would be happy if
there was a WG which was dedicated to this issue, even if its output would
be only a list of "recommended practices" explaining how exactly to use
existing XML standards to achieve this effect.

Since you've asked, I do have some notions as to how the above could be
done. First, I think that some of these questions aren't quite the right
ones. By this I mean that DTDs or XSchemas or whatever should be restricted
to defining the structure of a valid XML document. Viewed this way it
sharing DTD/XSchema fragments shouldn't be too hard. "All" you'd need to say
is "and this element is as defined in the following DTD". Trivial issues
such as namespace management are left as an excersize to the reader :-)

Assuming this issue is resolved, there remains the question of how to share
stylesheet fragments. Given that this is a completely separate issue, XSL
already provides ways to do this. "All" you need to do is provide a "library
module" stylesheets containing the templates for some functionality -
transforming certain elements in certain ways. The ability to specify
template modes and names is invaluable here; it ensures that these "modules"
won't be invoked unless you explicitly activate them.

Note that nothing stops you from providing a DTD/XSchema "fragment" and an
associated XSL one, if you insist on tight coupling between the two. But you
can also provide multiple XSL fragments for the same DTD/XSchema one, for
separate styling/transformation goals. You could also provide XSL fragments
which were applicable for a wide range of DTDs - consider for example the
IE5 XSL stylesheet for viewing arbitrary XML documents. In short, I strongly
feel that the assumption that a DTD "has" a stylesheet is wrong. As long as
it is being considered, this issue will get nowhere.

BTW, all this relies heavily on the XML namespace mechanism and the use of
URIs, and otherwise builds on existing XML standard. However, these
standards haven't been fully adjusted to namespaces yet. For example,
there's at least one potential problem in XSL - AFAIK mode and template
names can't be URIs, they must be simple names. I'll raise this issue in the
XSL mailing list. A WG dedicated to this issue could go through all XML
standards to ensure they match these scheme, and could make a better case
for changing a particular standard if necessary.

Another issue you mentioned is user control over this process. I think this
ultimately falls in the domain of application designers. Almost by
definition, end users will _not_ write CSS stylesheets or (shudder) XSLT
stylesheets. They will expect to be able to select from a menu of predefined
presentation options. It is an interesting question where these predefined
options can be defined in an "application independent" manner. That's the
only option which would guarantee users a freedom of presentation formats.

However, as long as the W3C promotes the "single conversion" document
processing model: "arbitrary data" + "stylesheet" -> "presentation format",
there will be no application independent stylesheets. If you want them,
there's no way around "arbitrary data" + "application dependent
transformation" -> "universal semantics", then + "application independent
stylesheet" -> "presentation format". The trick is defining the "universal
semantics" language, of course.

Currently the only candidate is HTML, and since it is a horrible universal
semantics language you can't really write application independent
stylesheets for it. It might be too late for the W3C to start developing
such a language, anyway - not that they are even trying. Barring someone
else doing it, there will be no application independent stylesheets. A pity,
really.

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)