On 12/5/06, James M Snell [EMAIL PROTECTED] wrote:
Mark Baker wrote:
It's just an entry without a feed. You'd use the same code
path to process that entry whether it were found in an entry
or feed document, right?
Not necessarily... The majority of applications that most
frequently handle Atom
I'm fine with the type parameter approach so long as it is effective.
By effective I mean: Will existing implementations actually take the
time to update their behavior to properly handle the optional type
parameter.
- James
Bob Wyman wrote:
[snip]
James suggests: the type parameter is
Bob Wyman wrote:
[snip]
What you seem to be implying is that the majority of applications
that process Atom Feed documents are not, in fact, supporting extremely
important parts of the atom specification. I believe that any properly
[snip]
Not quite. What I'm implying is that not all
On Dec 8, 2006, at 6:49 PM, James M Snell wrote:
Not quite. What I'm implying is that not all applications have the
need
to implement the entire specification.
At this point it would be a really good idea to be clear about the
original
intention of the specification and then propably
On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen
[EMAIL PROTECTED] wrote:
But that is an issue of linking semantics, not link target media types.
Wrong. The link relation 'alternate' is perfectly valid for both Entry and
Feed documents, depending on what type of resource they are
On Fri, 08 Dec 2006 18:52:05 +0100, James M Snell [EMAIL PROTECTED]
wrote:
I'm fine with the type parameter approach so long as it is effective.
By effective I mean: Will existing implementations actually take the
time to update their behavior to properly handle the optional type
parameter.
On 12/8/06, Asbjørn Ulsberg [EMAIL PROTECTED] wrote:
On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen
[EMAIL PROTECTED] wrote:
But that is an issue of linking semantics, not link target media types.
Wrong. The link relation 'alternate' is perfectly valid for both Entry and
Feed
