OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] FW: [link draft] Changing the model for links


Title: RE: [xri] FW: [link draft] Changing the model for links

Could both camps be accommodated by saying that you have a special rel, say '*' which ties together the rel preceding it and the rel following it (e.g. rel="stylesheet * alternate")?

Means extra work on those of us who having been using rel="x y" to always mean 2 relationships, but at least it's distinguishable as one relationship and you could check for presence of '*' relationship and not process special if it didn't exist. Other benefit is that such relationships can be represented as stylesheet*alternate xri subsegment.

Someone would need to sell the HTML5 guys on the need though, but given this may break several microformat mash-ups I wouldn't think it would be a tough sell.

=Bill.Barnhill


-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thu 4/9/2009 1:59 AM
To: 'Eran Hammer-Lahav'; xri@lists.oasis-open.org
Subject: RE: [xri] FW: [link draft] Changing the model for links

Man, this is a mess. It appears the whole root of the problem (which you can
see at http://www.w3.org/TR/html401/present/styles.html#specifying-external)
is that HTML 4 decided to create their own "keyword modifier" for values of
the rel= attribute in links. So you can insert the word "alternate" in front
of "stylesheet" (separated by a space, i.e., rel="alternate stylesheet") to
designate that it is an alternate stylesheet.



By coming up with their own semantics for how two independent strings modify
each other as values of the rel attribute, they screwed up everyone else who
would simply want it to be able to contain multiple values.



What were they THINKING???? It completely blows the regularity and elegance
of the architecture.



I don't know about anyone else, but I feel they have set such a bad
precedent here that I don't think we or anyone else should be obliged to
follow it. I think we should stick to the rel attribute accepting multiple
space-delimited values, and just accept that if certain of those values have
a relationship to certain other of those values, that's application
specific.



Otherwise we'd end out completely screwing up the link model (and XRD 1.0
architecture that is based on it) to accommodate somebody else's bad
decision.



I propose we make this the lead (and maybe only) topic on tomorrow's XRI TC
telecon because it's so important to get this feedback in now.



=Drummond



  _____ 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wednesday, April 08, 2009 8:39 AM
To: Eran Hammer-Lahav; xri@lists.oasis-open.org
Subject: Re: [xri] FW: [link draft] Changing the model for links



I forgot to mention this discussion is taking place on the HTTP list
ietf-http-wg@w3.org

EHL


On 4/8/09 8:22 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

This will have significant impact on XRD. Please read.

EHL


------ Forwarded Message

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 7 Apr 2009 16:21:34 -0700
To: <www-tag@w3.org>
Subject: Fwd: [link draft] Changing the model for links






Begin forwarded message:

> Resent-From: ietf-http-wg@w3.org
> From: Mark Nottingham <mnot@mnot.net>
> Date: 8 April 2009 9:10:58 AM
> To: HTTP Working Group <ietf-http-wg@w3.org>
> Cc: Ian Hickson <ian@hixie.ch>
> Subject: [link draft] Changing the model for links
> Archived-At:
<http://www.w3.org/mid/C1CD0848-13F0-4FCF-91FF-52126622C3B8@mnot.net
> >
>
> I've been discussing the link draft with Ian Hickson, who points out
> that in HTML4, there's a difference between
>
> <link rel="stylesheet" href=""a"/> > <link rel="stylesheet alternate" href=""a"/> >
> and
>
> <link rel="stylesheet alternate" href=""a/> >
> (see <http://www.w3.org/TR/html401/present/styles.html#specifying-external

> > for the background of why these are different)
>
> In the current link draft, there isn't any way to express the
> difference between these; the underlying model is
>
> [ context ] ---[ relation type ]---> [ target ]
>
> where 'relation type' is singular.
>
> To accommodate this use, the model would need to be something like
>
> [ context ] ---[ list of relation types ]---> [ target ]
>
> noting that there may be more than one list of relation types
> between any context and target.
>
> Personally, I think that it would be only in pathological cases that
> it would be necessary to know the difference between the two (i.e.,
> real world Web pages will not point to a URI as both a stylesheet
> and as an alternate for themselves, so it's safe to say that even
> the first example above means that "a" is an alternate stylesheet).
>
> However, it is important for Link to interoperate well with HTML4.
> Also, the HTML5 folks plan to use this model for other purposes
> (e.g., "up up" to indicate a parent of a parent).
>
> The practical impact of making this change is that serialisations of
> links won't be able to collapse multiple relation types between two
> URIs into one link; they'll have to be separate to allow this
> interpretation.
>
> So, for example, if you have link types ['w', 'x', 'y z'] between A
> and B, it will have to be serialised as
>
>  Link: <B>; rel="w"
>  Link: <B>; rel="x"
>  Link: <B>; rel="y z"
>
> in HTTP headers, NOT
>
>  Link: <B>; rel="w x y z"
>
> because that's ambiguous.
>
> The alternative is to say that the 'stylesheet alternate'
> combination isn't specific to how it's serialised, but is tied to
> the occurrence of the links. I.e., when both relations are present
> in links between the same resources, these special semantics take
> affect. However, this does seem to directly conflict with the HTML4
> language (see link above), so I don't think doing so is viable.
>
> Comments?
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>


--
Mark Nottingham     http://www.mnot.net/





------ End of Forwarded Message




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]