Subject: PaceLinkConstruct

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 20:26:03 +0200

-1

Again in the current context. This excessively overloads the syntax in
terms of core functionality while losing the benefit of a controlled
extension axis.

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 13:16:28 -0600

> terms of core functionality while losing the benefit of a controlled
I'm +1 on this, with the possible exception of @rev.  None of the 
proposed values (given that the service.* values have been removed from 
link by PaceServiceElement, so can be removed from this proposal) seem 
to cause problems with the syntax to me.

I'm undecided about whether to be for @rev, or to prefer using just 
@rel.  Were we to stick with just @rel, we'd have a collision between 
@rel="comment" and @rev="comment".  The latter might be replaced by 
"@rel="in-reply-to" (PaceLinkParent) or something similar.  
@rev="update", whether it ends up in @rev or @rel might be better as 
"updates" (which would parallel "replaces" better).

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 13:53:26 +1000

-1 to trying to limit @rel to an enumerated short list.

the only redeeming quality is the explicit call for @rev, however that is
already mentioned/implied by other paces (and deserves a pace of it's own
probably).

e.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 22:15:55 -0600

On Friday, October 8, 2004, at 01:16  PM, Antone Roundy wrote:
> I'm +1 on this, with the possible exception of @rev.
Revising my position--I breezed too quickly over the part about a 
closed list of @rel values.  -1 to that.  +1 to moving the list of 
values from the API spec to the format spec.  +1 to the additional @rel 
values--they all seem like reasonable additions.  0 to @rev.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 12:29:18 -0600

On Friday, October 8, 2004, at 10:15  PM, Antone Roundy wrote:
> values from the API spec to the format spec.  +1 to the additional 
> @rel values--they all seem like reasonable additions.  0 to @rev.

Oops, I'm re-revising my position.  I would think the most logical way 
to indicate the target of updated.by, replaced.by, update, and replaces 
would be with an atom:id, which might not be dereferencable.  comment 
might also be so, though it could also be a link to a feed of comments. 
  So something other than <link> seems like a better place for those.

I'm afraid I'm now only +1 to moving the list of values from the API 
spec to the format spec, which is covered by PaceMoveLinkElement, so -1 
to PaceLinkConstruct.  @rev could be reintroduced in another proposal.