[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Version Control Commit by blade
inline On Aug 20, 2009, at 11:51 AM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Will Norris [mailto:will@willnorris.com] >> Sent: Thursday, August 20, 2009 11:47 AM >> To: xri@lists.oasis-open.org >> Subject: Re: [xri] Version Control Commit by blade >> >> not sure which commit these were actually on, but i have two >> comments. You modified Section 2.4.1 to read: >> >>> The one distinction is that link relationships described by the >>> <Link> element are between the resource described by the XRD (the >>> context resource) and the linked resources (the target resources), >>> and not between the XRD document itself and the linked resource. >> >> The addition here are the two parenthetical statements, "context >> resource" and "target resource". Both of these are new terms that >> are >> not present anywhere else in the spec. Some time ago we did away >> with >> the term "target resource" in favor of "linked resource". We also >> consistently use the phrase "resource described by the XRD" >> throughout >> the spec. It is a mouthful, and I'm not terribly fond of it, but it >> is accurate and the best we could come up with. I don't disagree >> that >> this sentence can be a little confusing with all the "resources" >> being >> thrown about, but I'm concerned about throwing in new terminology >> here >> that isn't at all consistent with the rest of the spec. > > It is how the HTTP-Link spec defines typed links... It might be a > good idea to borrow a bit of that language here to make it easy for > those familiar with the link framework. That may be. I just want to make sure we're consistent. >> You added the following paragraph to the end of Section 2.5.1: >> >>> New relation types between resources must follow the extensibility >>> and registration requirements defined in [HTTP Link Header]. >> >> While I don't disagree with this, I'm curious if it's necessary. The >> whole reason link-header had to create a registry is because it is >> using tokens for registered values, and only using URIs for extended >> values. XRD is specifically using URIs only, so we don't really care >> about the token values. The universal rule of URIs is that you don't >> make up new URIs in namespaces you don't own. That would imply that >> you can't make up a new relationship in the >> "http://www.iana.org/assignment/relation >> " unless you've properly registered it. Now, I do like having some >> kind of reference because it instructs publishers how to format those >> token values as URIs, but the wording of the above paragraph seems >> out >> of place, given how XRD uses these values. > > We are not using just URIs. Note we don't have any requirement for > absolute URIs for <Rel>. A 'describedby' rel type is perfectly valid. Now that's really interesting... I hadn't considered "describedby" to be a valid value for <Rel>. I'm actually not too fond of that, and am now wondering if we *should* in fact mandate an absolute URI here. > I think it is important to point out to developers that if they want > to create new relation types, they should consult the link spec for > directions and guidelines on when to mint a short name and when a > URI extension. Fair enough. Perhaps move this paragraph to the extensibility section of the spec then?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]