Re: PaceLinkByLocation et al--what is a "link"?

[Graham]

Yep, Antone. Although no one actually has a use for generically-findable link elements, we seem to be stuck with them anyway, and stuck with creating a brand new namespace mechanism for it for no reason. Never mind. Maybe there's another atompub group somewhere we can join that isn't so pigheaded about this.

Graham

On 15 Nov 2004, at 5:27 pm, Antone Roundy wrote:

With something akin to PaceLinkPurpose (which is in the recommended for closure list...a fact I will object to here, but unless somebody else speaks up, I won't waste any more effort advocating it), I think the value of PaceLinkByLocation, PaceConstructAttribute, PaceFieldingLinks, and PaceLinkRelPrefixReg is limited mostly[1] to name collision avoidance. In other words, unless Link Constructs are constrained to the point where an application can handle unknown Link Constructs in some default way without...how to say it...doing something stupid, it doesn't matter whether the application can recognize unknown Link Constructs or not.

[1] PaceConstructAttribute might have some usefulness with respect to other construct types (BTW, the list of its values needs to be expanded to include one for each construct type defined in the spec...I'll have to get to that). PaceFieldingLinks also defines a default @rel value, and pares down the list of @rel values (...too much, in my opinion, but I'd rather argue that later).

smime.p7s
Description: S/MIME cryptographic signature