XLink: behavior must go!

[Simon St.Laurent]

At 06:23 AM 5/12/99 -0500, Paul Prescod wrote:
>This probably isn't the best week to send this but you can't always choose
>when inspiration (or religious fervor) will come to you. The message is
>widely crossposted because it crosses disciplines but I would like to see
>discussion be restricted to XML-DEV or offline. (I choose XML-DEV over
>xlxp because more people are subscribed there right now.

Per Paul's request, I'm responding to XML-Dev.  Is there ever a good week
for inspiration?  I'd love to find one.

Paul's message has lots and lots of parts to it.  Rather than sending 35K
replies back and forth, I'm going to try to focus on some parts I think
make a good beginning.  I'd also like to distill this down to a core
proposal people can discuss.

>I believe that the XLink behavioral attributes should be removed.
>Theoretically they mix presentation and structure. This causes all kinds
>of practical problems addressed below:

I'm not yet with you completely on removal of these attributes, but I'll
certainly agree that the many components of XLink that deal with behavior
range from the extraordinarily vague to the excessively specific, without
very much in the middle.

>Also, XLink's behavior attribute is a car-wreck waiting to happen. What if
>Microsoft and Netscape use it differently?

Agreed, though I think train-wreck is a more appropriate scale.

> Problem: complexity
>
>Let's radically simplify the XLink specification and *get it out the
>door*. Taking behaviors out will help.

Problem: Getting it out the door.  I've been wanting to push (and use)
XLink for the last two years.  It's very hard to get people excited about
something that has a vague draft that's over a year old.  Getting the spec
out the door will help sell XML as a general-purpose solution to a wide
variety of problems that afflict webmasters every day.  Simplifying it will
ease that selling considerably.

> Solution:
>
>Take all references to behavior and traversal out of the XLink spec. Move
>it all into a pair of specification called "Extensions to XSL for Link
>Rendering" and "Extensions to CSS for Link Rendering."

I'd like to make this as concrete as possible.  Does this mean that you'd
be looking at something like the model below for describing extended links?

<!ATTLIST myLinkContainer
	xml:link	CDATA		#FIXED 'extended'
	inline 		(true | false)	'true'
	link-role	CDATA		#IMPLIED
	content-role	CDATA		#IMPLIED
	content-title	CDATA		#IMPLIED>

<!ATTLIST myLinkLocator
	xml:link	CDATA	#FIXED 'locator'
	locator-role	CDATA	#IMPLIED
	title		CDATA	#IMPLIED
	href		CDATA	#IMPLIED>

(These come more or less from the XLink WD, minus the parts Paul doesn't
like. I've renamed some of the role attributes to try and make things a bit
clearer. myLinkContainer and myLinkLocator are placeholders, of course.)

Style sheets would have to deal with the various roles and piece together
appropriate behaviors.

A key concern for me is making sure that CSS and XSL use a similar model
for processing links and that that model can also be used by applications
that wouldn't normally use style sheets.  (The simple image map example on
my web site is a very simple case, but there are a few thousand other
possibilities.)

Rather than going directly to implementation in CSS and XSL, I'd like to
see an intermediate step describing what exactly is 'in' a link, and
possible mechanisms for moving from raw sets of locators to traversable
paths (including what might be on that pop-up menu or equivalent.)

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

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)