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
To put it mildly, not a chance in hell. :-)

EHL


On 4/10/09 1:33 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:

Eran, thanks, this considerably relieves my angst about this issue. I really
didn't want to be screwing up XRD architecture to accommodate this.

=Drummond

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Thursday, April 09, 2009 6:53 AM
> To: Barnhill, William [USA]; Drummond Reed; xri@lists.oasis-open.org
> Subject: Re: [xri] FW: [link draft] Changing the model for links
>
> I think at most, the link spec will call out the existing deployment of
> alternate with a few other rels and deprecate this practice. If anyone
> wants
> to create combinations, they should just define new rel types. Even media
> types based on +xml or +json still needs to be individually registered, so
> that is the common practice here.
>
> Since <Rel> does not old multiple values, we do not have a way to express
> this combination in XRD anyway. Separate <Rel>s are semantically
> equivalent
> to:
>
> Link: <a>; rel="a"; rel="b"
>
> Which does not fall under the HTML4 issue.
>
> So for us it is simply a matter of not being able to express this use case
> (which is a good thing).
>
> EHL
>
>
> On 4/9/09 5:02 AM, "Barnhill, William [USA]" <barnhill_william@bah.com>
> wrote:
>
> > 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]