XLink: behavior must go!

[Martin Bryan]

John E Simpson wrote

>Would it be fair to say that the behavior attribute of an XLinking element
is intended to function as a sort of localized (element-context-specific)
PI -- a trigger to XLink-smart processors that is ignorable by others? If
so, in what way is such an attribute more problematic than actual PIs?

The key point about the behaviour attribute is that it is instance specific,
rather than element-context-specific. (You can deal with all
element-context-specific problems in the stylesheet; it is instance specific
changes that are the difficult ones to control without passing some form of
control parameter.)

Oren Ben-Kiki wrote:

>If you can define a set of behaviors and make a good case that this set is
applicable to the vast mojority 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. I am not
convinced that the behaviours needed for the US Defense industry will be the
same ones needed by the European healthcare industry (in fact I know they
are different). Why should I seek to impose the requirements of one of these
groups on the other? What is needed is a standard "point of reference" that
people can know where to go for information.

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">. Note
that the name of the parameter entity used to define behaviour is
remote-resources-semantics.att - its the semantics we should be passing, not
the calls. Note also the subtle change to the last example. Behaviour
belongs on the locator rather than the link set. For simple links these are
the same thing but for extended links this is not true. The key point is
that for multiheaded links behaviour is controlled at link instance level.
It is for multiheaded links that you need to control the behaviour of
different members of the link set in different ways.

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.

Ben 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.

I had said:
>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.

Ben responded:
>The 'behavior' attribute as it is specified - or should I say,
unspecified -
today, does not give you this power. As long as it doesn't have a set of
well-defined valid values, it is wores then useless.

I agree it is under-specified. I think it is too early (by 3-5 years rather
than Ben's estimate of 1 year) to specify a decent set of acceptable
procedures. I think the best we can do at present is to take the approach
namespaces did - point to a resource that describes what is required and
depend on the system having its own rules for resolving what that means.

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)