2006/3/24, James M Snell <[EMAIL PROTECTED]>:
> 1. Do I change to ?
+0.5, I have no real problem with id but as it seems to bother some people…
> and.. to address David's concerns about extending atom:link...
>
> 2. Do I change thr:count and thr:when to extension elements instead of
> attribut
* James M Snell <[EMAIL PROTECTED]> [2006-03-24 21:30]:
>1. Do I change to ?
+1, in case my implicit vote isn’t already counted.
>2. Do I change thr:count and thr:when to extension elements
>instead of attributes on atom:link?
+0; but I don’t plan on using those on either end of the wire.
Re
James M Snell wrote:
1. Do I change to ?
I don't know enough to care what you call those attributes. And it's a long
way before we'll go live with anything so if you need to change attribute
names it wouldn't bother me in the least.
2. Do I change thr:count and thr:when to extension ele
Sylvain Hellegouarch wrote:
>
> Hi James,
>> For me it's a matter of the fact that the spec has gone through 6
>> revisions and two design overhauls since it was first pitched. It's
>> been out there for quite a while. At some point, the design discussions
>> need to end and it needs to stabli
Hi James,
For me it's a matter of the fact that the spec has gone through 6
revisions and two design overhauls since it was first pitched. It's
been out there for quite a while. At some point, the design discussions
need to end and it needs to stablize so that folks can do something real
with
For me it's a matter of the fact that the spec has gone through 6
revisions and two design overhauls since it was first pitched. It's
been out there for quite a while. At some point, the design discussions
need to end and it needs to stablize so that folks can do something real
with it. If, dur
David Powell wrote:
> Friday, March 24, 2006, 3:28:02 AM, James Snell wrote:
>
>> I believe the concern is over the thr:count and thr:when attributes for
>> the replies link relation, both of which are optional, and both of which
>> provide what I consider to be extra information. In other word
Friday, March 24, 2006, 3:28:02 AM, James Snell wrote:
> I believe the concern is over the thr:count and thr:when attributes for
> the replies link relation, both of which are optional, and both of which
> provide what I consider to be extra information. In other words, it's
> ok if an implemen
Just wanted to follow through on this for everyone. Given that there
are vendors getting ready to ship code based on the current rev of the
spec, I'm *not* going to rename the "id" attribute to "ref". Yes, I
know that "id" is confusing to some folks, but we're just talking the
name of a singl
David Powell wrote:
>[snip]
> The abandonment of extension constructs in favour of undefined markup
> by this draft, and other draft-*-atompub-* drafts would be an
> interoperability concern if these drafts were deployed. If you want to
> extend Atom, use Extension Elements.
>
I'm most certainl
I believe the concern is over the thr:count and thr:when attributes for
the replies link relation, both of which are optional, and both of which
provide what I consider to be extra information. In other words, it's
ok if an implementation drops them. The important bit is the
in-reply-to element
* David Powell <[EMAIL PROTECTED]> [2006-03-24 02:20]:
>The abandonment of extension constructs in favour of undefined
>markup by this draft, and other draft-*-atompub-* drafts would
>be an interoperability concern if these drafts were deployed. If
>you want to extend Atom, use Extension Elements.
Thursday, March 23, 2006, 9:39:09 PM, James M Snell wrote:
> Just wanted to follow through on this for everyone. Given that there
> are vendors getting ready to ship code based on the current rev of the
> spec, I'm *not* going to rename the "id" attribute to "ref". Yes, I
> know that "id" is c
Just wanted to follow through on this for everyone. Given that there
are vendors getting ready to ship code based on the current rev of the
spec, I'm *not* going to rename the "id" attribute to "ref". Yes, I
know that "id" is confusing to some folks, but we're just talking the
name of a single a
Andreas Sewe wrote:
> @ref, however, sounds like an entirely reasonable name for such an
> attribute.
>
I'm coming around to this view as well. On the downside, there are
implementations of the draft that are being prepared now, I will ping
the folks who I know are implementing and see if a na
Considering the above-mentioned symmetry with @href, I’m coming
around to whose-ever view it was that this attribute should be
called @ref for balance.
+1 for @ref as well.
Thomas Broyer <[EMAIL PROTECTED]>:
Sylvain Hellegouarch <[EMAIL PROTECTED]>:
I would rather move the content of that attribute as a text
element of the 'in-reply-to' element (as does the atom:id
element).
I raised a similar issue regarding James Snell's Feed Rank I-D where a
ranking:scheme
* Thomas Broyer <[EMAIL PROTECTED]> [2006-03-16 20:15]:
>2006/3/16, Sylvain Hellegouarch <[EMAIL PROTECTED]>:
>> Atom sets the atom:id value not as in an attribute of atom:id
>> but as its content. Why not following the convention in the
>> first place?
>
>Because they don't deserve the same role.
2006/3/16, Sylvain Hellegouarch <[EMAIL PROTECTED]>:
> > It could lead to confusion, but as Atom doesn't define such an
> > attribute in its own namespace (or on elements in its own namespace)
> > and as no other extension that I know of do that either, I don't think
> > it really matters…
>
> You
Hello Thomas,
It could lead to confusion, but as Atom doesn't define such an
attribute in its own namespace (or on elements in its own namespace)
and as no other extension that I know of do that either, I don't think
it really matters…
You are right Atom does not define such an attribute b
2006/3/16, Sylvain Hellegouarch <[EMAIL PROTECTED]>:
> Calling such an attribute 'id' is a mistake in my opinion as it confuses
> with the actual ID of the element itself within the XML document it
> belongs to
It could lead to confusion, but as Atom doesn't define such an
attribute in its own na
21 matches
Mail list logo
