Re: XLink and Style

At 04:13 PM 4/12/99 -0400, Paul Prescod wrote:
>Actually, I don't think we need to look at or care about XLink in
>particular at all. Not all standards can be orthogonal but when they can
>be that is best. Instead of looking at XLink, we can proceed from first
>principles:
>
>XML is designed to allow the separation of semantic content from
>presentation. This allows the two to be separately persistent or
>ephemeral. This separation applies as much to links as to paragraphs and
>emphasis.

Okay, we _can_ go back to first principles, every time, but I think we're
going to get into an ugly "what is semantic and what is presentation"
argument that might be better avoided by considering the particulars of
XLink and what it expects of style sheets.  This gets especially messing in
some data-processing applications where there is no 'presentation' in the
usual sense of the word, though perhaps behavior is a good description.

>Therefore a stylesheet language should be able to express a wide range of
>presentations for the link ends of links. Ideally, we would use the HTML
>presentational features as a starting point (as we do for presentation)
>and add more sophisticated stuff over time.

The problem here is that XLink is asking style sheets to do considerably
more than present link ends; eventually, we're going to have to deal with
the question of how those link ends are determined and which paths are
traversable, if the current spec's language survives to the rec.

>This implies that a stylesheet language should be able to express the
>presentation and behaviour of the HTML A element type and the HTML IMG
>element type. The LINK element type has never achieved popualarity in user
>interfaces so it is arguably out of scope.

We'll have to deal with LINK in the context of connecting style sheets to
documents (if we ever want to move beyond PIs), but otherwise this is
reasonable.  

>> * Handling inclusions, transclusions, and new windows because of the show
>> and actuate axes of XLink.
>
>The stylesheet language should handle inclusions, transclusions and new
>windows *in spite of* the show and actuate axes of XLink. Those are only
>presentational hints, not instructions.
>
>As the XLink specification says, "ideally behavior is handled in a
>stylesheet" (paraphrased).

The XLink draft describes this as 'express a policy', not give a
presentational hint.  It would be simpler, perhaps, if XLink dropped these
features entirely.  On the other hand, it might make it more difficult to
repurpose documents created with XLink for use with multiple style sheets.

"Since XLink provides only the most general semantics for links, details of
presentation, such as time delay or beep before forwarding, can be
specified on a per-application basis using a style language."

That doesn't sound like much is left to the discretion of the style
language, but again, that could change.

>If the XLink spec did not exist then there would be no question that
>linking behaviors belong in the stylesheet language (as they do in the
>dozens of existing SGML and XML stylesheet languages). If the spec. did
>not mention behavior at all then it would be similarly easy to see that
>behavior is a stylesheet's responsibility. That follows from the first
>principles.

If we accept your first principles as axioms, then perhaps.  But remember
that I don't see this distinction as plainly, and I still have yet to be
convinced that non-presentational uses of XLink should be forced to rely on
style sheets for processing.  Seems like a huge waste of processing.  For
traditional document processing, fine, but for data-oriented applications,
forget it.  I know of several projects using XLink to describe
relationships between objects - why on earth would they use a style sheet
processor?  (Because they could seems an inadequate answer.)

>But the spec does mention behavior. Nevertheless, it is pretty clear that
>the intention is not to let stylesheet languages abdicate their roles as
>style determiners. I would say that the behavior attributes should be
>observed only when there is no stylesheet or the stylesheet has nothing to
>say about link presentation.

Or, perhaps, the style sheet could be used to interpret the behavior
attribute's meaning and process it accordingly.  That seemed a popular
argument on xlxp-dev last December.

>The main problem is that you are not supposed to be forced to embed the
>processing information in either your document or your document type. You
>may want to embed definitions in one view of the document and make
>hyperlinks to them in another view. Different stylesheets should be able
>to express the different views.

It sounds here like you want to overturn the entire attribute-based
approach to XLink.  In any case, I'd like to have some solid foundations in
XLink that don't require the use of style sheets per se.  Making them
cooperate with style sheets is important, but making them disappear into
style sheets seems like overkill.

>Consider also the problem of print. If you use any combination of XLink
>attributes *other than* show="embed" and acutate="auto" what does that
>mean to a print rendition of the data? I hadn't thought of this much
>before but I find it fairly disturbing. A more media-agnostic view would
>be a single attribute: xml:link-type="embed|reference". Then the
>stylesheet could handle replace versus new and auto versus user.

Never had much use for print, frankly.  If it can't keep up, it doesn't
really bother me.  Seems to me like the W3C is the World Wide Web
Consortium, not the Hand-Typesetters Association, but I can't find
difficulties in linking print that bothersome.  We do, after all, have
indices and tables of contents for such applications, and you can always
transform your documents (XSL or architectural forms) if it's really that
important.


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

Received on Monday, 12 April 1999 18:04:52 UTC