Re: XLink and Style

At 05:22 PM 4/14/99 -0400, Paul Prescod wrote:
>> 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).

My concern here is that while the nature of an XLink used in a particular
context may be clear (content, presentation, metadata, something else), the
relationship between linking in general and style sheets is not likely to
be as clear, and the presentation/content distinction isn't always as
simple as it might seem.

I'd rather focus on the problem solving than 'first principles', and it
sounds like you agree.

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

I can make cases for all of these in data processing.  Actuate allows for
delayed handling, triggered by a program 'user' when needed.  New and
replace can refer to objects as easily as windows.  In this context, embed
is very useful, though embedding fragments could be a headache.

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

Link ends had better be done by XLink and XPointer; that seems to be about
all they really tell a program at present.  Relying on style sheets to
figure out traversable paths seems like a disaster to me, but then I've
always been more interested in the traverses than just the set of link ends.

For data processing, this could pose some strange problems.  'Traversal'
can still have lots of meaning in this context, but CSS and XSL aren't a
good fit.  On that end, I'll like to see XLink itself provide more guidance.

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

See above; I clearly disagree.  They may not seem important for your
non-presentational applications, but there is plenty of room for making use
of these concepts within a program as well as within an interface.

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

Yes, but does it make sense to print the 'links', or does it make sense to
print the presentation created using those links?  You can always write
code that does something like 'print all linked documents' including the
popups in new windows, and using XSL you could munge it all together into a
single document - processing the link elements to your own specs - if you
wanted.

Dependent on the Web is something that's going to happen anyway.  Media
types are like that - assuming that information is information and should
be able to move across media boundaries smoothly is a very dangerous
position.  While we can accomodate presentations in multiple media with
style sheets, I'd really rather have style sheets that work well on the Web
than style sheets that work well in print and can be tolerated on the Web.

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

How is lynx going to cope with very much of this at all?  How does lynx
cope with CSS? XSL?  A single-window text browser is nearly as limited as a
printed book.  It serves a clear purpose, for lots of users, but I suspect
XLink in general is going to be a problem for that tool, not just the
behavioral end of it.  (I'd love to see what they come up with, if they
address it.)

XLink 'conformance' in general is an important issue, though I wonder if
we'll be seeing much in the spec about it?

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

Received on Thursday, 15 April 1999 08:16:07 UTC