RE: CSS and XLink

Hi Simon,

You're right to bring the spot there. In fact, the interaction of style
sheets and XLink is not so obvious especially in the case of browsers. When
a Xlink is resolved and points to a XML document or XML fragment, it cannot
be rendered unless a style sheet is associated to it (as you already know).

The problem is when a XML document or fragment is inserted. Here are
conflict that can occur (we got them all with our experiments :-)

a) XML markups name space collision. The pointed document may not have all
its elements included in a specific name space. The solution we found is
a) check if the pointed document has a XML name space
	- if yes, check if the name space name itself do not collide with the
document already processed in the browser.
		if there is a collision: create a new name space identifier and re-tag all
document with the new name space
		if no collision take it as is.
	- if no, include the XML document with its name space as is.
So far so good. This step is just to be able to process the document.

b) possible failures from now on:
	- The original document style sheet do not include the included document
name space elements-> breakdown
	- The original document style sheet includes the included document name
space elements but the included document author changed its name space
identifier-> breakdown
	- The included document do not have name space identifier, the document has
been modified and now includes conflicting elements. breakdown in style
sheet :a) how to name the included element if no name space is present.

We saw with the experiment that XML is more fragile than actual HTML except
if:
a) All document are de facto in a name space. The name space being the
domain name. the domain name is a unique context within the DNS name space.
This could be automatically assigned even if no name space is provided by
the author. Otherwise, it the responsibility to expose a name space
identifier is left to the author, we not have a name space identifier and
then a possible breakdown.

However, we did not found any way to resolve the problem of style sheets
that could be applied without any problem to the original and included
document.

Conclusion: when used only without links XML and style sheets are quite
robust because the world is often controlled by the same authority. When
linkage between documents occurs, serious potential problems occurs (several
hundred millions users, several million sites!!!). We just scratched the
surface...

I guess this is why the XLink group is jammed. The combination of XML
documents and style sheets is really not obvious especially if you want to
connect documents from external source where you don't have any control. The
rules become very important then. HTML got an easy life on this point
because the language is already defined. XML means that several languages
have to interact, with several thousands if not more potential languages,
XML is more complex.

So, you just put the spot on a troubled part of scene: XML links and style
sheets. Or "XML document linking and rendition". This could be the title of
a fun sci-fi movie or an horror movie, it depends of the scenarists :-)

Regards
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com
-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org]On
Behalf Of Simon St.Laurent
Sent: Monday, April 12, 1999 10:13 AM
To: www-style@w3.org
Subject: CSS and XLink


The XLink work at the W3C (latest draft, which is getting ancient:
http://www.w3.org/TR/WD-xlink) seems to be throwing a lot of work in the
direction of style sheets.

>XLink does not provide mechanisms for controlling link
>formatting because it is considered to fall into the
>domain of stylesheets. Link behavior should ideally also
>be determined by rules based on link types, resource roles,
>user circumstances, and other factors.

It's not clear what the full scope of the work handed to style sheets will
involve, but it is clear that this work will involve more than describing
formatting for link ends.  The work may involve:

* Formatting link ends (easy)
* Determining the traversal paths between link endpoints (complex, save for
later)
* Handling inclusions, transclusions, and new windows because of the show
and actuate axes of XLink.

To put it simply, XLink provides three options for show: embed, replace,
and new. Embed adds the content of the target resource to the document
(though it remains sort of a visitor), replace replaces the resource
(document) making the link with the target resource, and new displays the
target resource in a new window.  The actuate axis provides auto and user
as options.  Auto means that the embed/replace/new activity should take
place automatically, while user means to wait for 'an explicit external
request for traveral' - like a mouse click.

Using these tools, we can recreate the HTML IMG element as:

<img href="mygraphic.gif" show="embed" actuate="auto" />

(I haven't taken the step to convert href -> src, which complicates things
a bit.)

The question that XLink leaves unanswered, and which CSS doesn't deal with
directly, is the conversion of this element to a graphic on the screen.  In
HTML, this was an explicit property of the IMG element, but in XML, you can
replace IMG with anything:

<myFunkyCoolGraphic href="mygraphic.gif" show="embed" actuate="auto" />

This should still work, just like IMG did.

In my opinion, mechanisms like MIME types should be capable of handling
this.  The application hits the element, sees that it's an XLink, retrieves
the resource, sees text/gif as a MIME type, and displays it as a graphic.
Not that difficult.  Maybe a "display:graphic" option would help it along,
if so desired.

Other people see this as an enormous problem for CSS, more evidence that
CSS isn't a good fit for XML (see
http://lists.w3.org/Archives/Public/www-svg/1999Apr/0011.html for an
example).

What do people think? There's going to be a lot of work to do in this
field, once the XLink working group gets cranked up again.  XLink has
truckloads of potential, but I'd like to make sure it gets implemented
right and that its implications for other fields (style sheets in
particular) are clear.

Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com

Received on Monday, 12 April 1999 11:17:22 UTC