Re: [paq] using anchor or different links

Yogesh,

Yogesh Simmhan wrote:
> | But I'm a bit confused by the references here to "The anchor name itself can
> be
> | used as the actual header/tag/attribute name".  What we're actually proposing
> | here is a new link relation type for use primarily in an HTML <Link> element.
> |
> Since the IETF Web Linking spec provides HTTP with context-uri's that use the
> "anchor" parameter to perform the same job as the "target" relation we
> introduce, the suggestion was to use the built in context-uri feature for
> documents retrieved using HTTP instead of introducing a new HTTP Web Link
> relation.
 >
> An equivalent parameter does not exist in the HTML Link element. So we will need
> to introduce a new relation in HTML as is being done in the PAQ (currently
> called the target). The comment was concerning what we call this relationship.
> In order to strive for consistency across HTTP Web Linking and HTML Link
> element, we may consider using "anchor" or "context " as the relationship name
> in HTML, rather than "target".

OK, thanks for clarifying.  That's what I hoped you meant, but it wasn't clear 
enough to me from the earlier text.

> However, it is true that we may end up conflating a HTTP parameter (anchor) with
> a HTML relationship (anchor/context-uri) by introducing the relation only in
> HTML and reusing a parameter in HTTP. So one may argue that the new relation
> must also be introduced in HTTP to be consistent. I was looking at making the
> least set of changes and keeping names/concepts consistent even through these
> changes.

Yeees... I'm not sure which way is cleanest.   There are some fairly obscure 
possible use cases that might be handled by the separate relations, but not by 
the Link anchor parameter.  But I think they are so obscure that I wouldn't use 
them to argue against a moderately compelling case for the other.

#g
--

Received on Monday, 15 August 2011 16:03:20 UTC