XLink: behavior must go!

[Paul Prescod]

Martin Bryan wrote:
> 
> 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.

I think some people are going to want a little of each. I don't advise
either one in general but maybe in some cases it makes sense.

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

If you define common values for the attribute then I will be able to
evaluate the usefulness of your idea. But if you are just talking about a
common attribute name then I'll refer you back to my argument that this is
worse than nothing because it encourags people to make incompatible
documents and pretend that they are compatible by virtue of the attribute
names.

How do I map attribute values to real, honest to goodness behaviors in my
browser? I'm not clear what your proposal is nor how it relates to the
behavior attributes in XLink today.

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

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?

Nevertheless, fetching data out of your database is not a behavior
problem. Transforming nodes is not, according to my terminology
"behavior". It is addressing or "viewing" or even "rendering". In the "web
model" the way to do this is to define a new form of URL: sql://[select *
from blah]. Of course the URL model does not have a way to turn that into
nodes. That's why I say you need the grove model. I guess the "web way" to
do this is:

http://www.mysite.com/cgi-bin/fetchdata?select * from blah

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

If that's true then that's a problem with DTDs or XMLSchema's. It is
generally useful to be able to subtype and extend other people's DTDs.
Architectural forms allow it but so will XMLSchema.

> 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

If you are talking about fetching data then you should use CGIs or groves.
Its an addressing problem, not a behavior problem.

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

Once again you are talking about a flaw in another part of the system. I
don't quite understand your need but it seems far afield of a behavior
attribute.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Earth will soon support only survivor species -- dandelions, roaches, 
lizards, thistles, crows, rats. Not to mention 10 billion humans.
	- Planet of the Weeds, Harper's Magazine, October 1998

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)