+1. I'd like to see language specifying how the namespace can be used
to determine compatibility between revisions of the specification--ie.
any app that can handle one version of Atom can handle any version
sharing the same namespace, and any feed that's valid under any version
of Atom is
PaceRemoveVersionAttr
-0
I suspect there are good social reasons to keep @version
I just had a thought (astounding!)
If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone to produce
Eric Scheid wrote:
I just had a thought (astounding!)
If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone
to PaceRemoveVersionAttr, particularly in light
of Atom being a Must Understand vocabulary.
--
Joe Gregoriohttp://bitworking.org
On 3 Feb 2005, at 9:36 pm, Graham wrote:
On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote:
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Yes. I like it too.
Just to clarify, I like it being there for
informational/statistics/debugging purposes. I don't see
Some thoughts
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds become legacy? Are people storing entries with
the expectation that
On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote:
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Yes. I like it too.
Graham
smime.p7s
Description: S/MIME cryptographic signature
On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote:
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds become legacy? Are
Norman Walsh wrote:
Some thoughts
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds become legacy? Are people storing entries with
of
this, but not all of it. Do we need something more?
That is what I am aiming for.
I put some placeholder text at the bottom of PaceRemoveVersionAttr, but
it definately needs to be expanded/improved.
- Sam Ruby
In its present form, I want to get rid of the version attribute. That's
not to say that I don't want something with more useful semantics, on a
separate axis from the namespace.
So, +1 to the Pace.
On Feb 3, 2005, at 1:18 PM, Norman Walsh wrote:
Some thoughts
- It seems very likely to me that
On Feb 2, 2005, at 8:22 AM, Sam Ruby wrote:
Much to my surprise, scanning the current document, I don't see any
must ignore text.
Hey, we just accepted PaceExtendingAtom 24 hours or so back, give Rob
Mark a chance :)
13 matches
Mail list logo
