W3C home > Mailing lists > Public > www-style@w3.org > April 1999

XLink and Style

From: Paul Prescod <paul@prescod.net>
Date: Wed, 14 Apr 1999 17:22:14 -0400 (EDT)
Message-ID: <3714E47A.8D9210BB@prescod.net>
To: www-style@w3.org
Sorry that reply-to doesn't work but I'm not yet getting posts from
www-style so I can't just "reply".

> Re: XLink and Style
> 
> Simon St.Laurent (simonstl@simonstl.com)
>
> 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. 

I don't think that the distinction between presentation and content is
usually so complicated. Typically I have a problem to solve -- if I embed
some information it limits the usefulness of the information. If I impose
the information externally then the information is more widely useful.
Typically that information is presentation (though there are other types
of redundancy).

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

Actually, I think that this makes it easier. It's pretty clear that in the
data processing world the "actuate" attribute is useless -- so it is
clearly presentational. The "new" and "replace" values of "show" are also
pretty clearly useless. Embed is arguable in that it could be used to
transclude content from somewhere else.

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

Which paths are traversable -- yes. Determining link ends should be done
by XLink and XPointer.

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

For the same reasons that it is a pain (relative to MSWord) to repurpose
paragraphs from one stylesheet to another -- you have to declare that P
means paragraph in each stylesheet! We can use stylesheet importing to
make this easier though.

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

A non-presentational use of XLink doesn't care about traversability, user
versus auto actuation etc. So all they need is the link -- they don't need
the stylesheet and they don't need the behavioral attributes either!

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

Most W3C standards support print because printing is an important part of
the Web experience. Furthermore, XLink is right *in the document*. It is
certainly not the role of the W3C to try and make people's documents
dependent on the Web. Usable on the Web, yes. Useless off of the Web --
no.

Anyhow, print is just an example. The behavioral attributes are not very
friendly to text browsers either. How does lynx "embed" versus "new" a
GIF? Is a conforming XLink browser going to be allowed to treat those two
options the same? If so, then I would say that the options are "merely
hints" that can be ignored?

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

By lumping computers and televisions together, as if they exerted a 
single malign influence, pessimists have tried to argue that the 
electronic revolution spells the end of the sort of literate culture 
that began with Gutenberg’s press. On several counts, that now seems 
the reverse of the truth.

http://www.economist.com/editorial/freeforall/19-12-98/index_xm0015.html
Received on Wednesday, 14 April 1999 18:23:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:59 GMT