2006/11/29, James M Snell:
The problem I have with the WHAT-WG definition of the alternate and feed
relations is the unintended conflict that occurs when the alternate
representation of a page happens to be an Atom Entry Document.
The HTML5 draft says,
If the alternate keyword is
I would like to have application/atomentry+xml for entry. As a result,
application/atom+xml must be a feed.
2. We add a type parameter to the application/atom+xml media type
to differentiate feed and entry documents,
e.g. application/atom+xml;type=feed,
http://www.intertwingly.net/wiki/pie/PaceEntryMediatype
#pragma section-numbers off
== Abstract ==
For the current Atom Publishing Protocol draft...
Create a new media type for Atom Entry Documents: application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
On Nov 29, 2006, at 5:16 PM, James M Snell wrote:
Create a new media type for Atom Entry Documents: application/
atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
That is a *very* good idea!!
+1
Jan
== Status ==
Proposed
== Rationale ==
The fact
-1
- there's nothing special about an entry document
- AFAICT (because they're not referenced from the pace), the problems
referred to have other causes. I prefer we fix those instead.
Mark.
Hi Mark,
would you suggest to put service and categories into application/atom+xml as
well?
Hmm, ah, I think I see what you mean: When a peer declares it understands
application/atom+xml the understanding of entry/ is mandatory anyhow. Despite
the additional inspection into the documents
One such problem occurs in atom:link and atom:content elements.
Specifically:
atom:link type=application/atom+xml href=a.xml /
atom:content type=application/atom+xml src=b.xml /
Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.
-
I'm fine either way. Wouldn't take that long for me to write up a draft.
- James
Tim Bray wrote:
On Nov 29, 2006, at 8:16 AM, James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceEntryMediatype
#pragma section-numbers off
== Abstract ==
For the current Atom Publishing
There are all kinds of other things you don't know: like what's
inside the document, if the server is up, what the title is, ... What
interoperability problem is solved by having a new mime type? And
would that not be solvable by
atom:link rel=entry type=application/atom+xml href=a.xml /
On Nov 29, 2006, at 8:16 AM, James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceEntryMediatype
#pragma section-numbers off
== Abstract ==
For the current Atom Publishing Protocol draft...
Irrespective of the merits of the new media type, the APP spec seems
like the wrong
On 11/29/06, Jan Algermissen [EMAIL PROTECTED] wrote:
Hi Mark,
would you suggest to put service and categories into application/atom+xml as
well?
I haven't paid much attention to those, but AFAICT they have different
processing models (e.g. extensibility rules) and so IMO, comprise
2006/11/29, James M Snell:
Create a new media type for Atom Entry Documents: application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
I'd largely prefer augmenting the existing media type with a 'type' parameter:
- application/atom+xml = either feed or entry
On 29 Nov 2006, at 19:17, Leons Petrazickis wrote:
We need to make the migration
from invalid XHTML to valid HTML5 very, very easy for them. We can't
require them to dig through PHP spaghetti. And that means that, no
matter how it's achieved, br/ needs to be valid HTML5.
+1
- Geoffrey
On 30/11/06 5:39 AM, Henry Story [EMAIL PROTECTED] wrote:
would that not be solvable by
atom:link rel=entry type=application/atom+xml href=a.xml /
not if you want to do this:
atom:link rel=something-else type=application/atom+xml href=a.xml /
where 'something-else' might be 'comments' or
Robert Sayre wrote:
[snip]
1.) IP Protections
This is interesting for a couple of reasons. One is that Mr. Snell
previously claimed that the document has nothing to do with my day
job [1]. The second is the complete absurdity of worrying about IP
protections on HTML tags that make an
Mark Baker wrote:
[snip]
Yes, but more than that. An entry document is, AFAICT, little more
than shorthand for a feed with one entry, minus the feed-specific
metadata. It's processing is a subset of feed processing. If the
processing or content model of entry is extended, it applies to
John Panzer wrote:
[snip]
+1 to doing this outside of APP (but concerned about deprecating...)
[snip]
An I-D / RFC can update another RFC without deprecating the entire
thing. In this case the hypothetical new document would deprecate only
the use of the application/atom+xml media type for
So this needs a decision tree:
+1 to having some way to modify type= (either new media type, or
appending ;type=entry, +0 to either)
+1 to application/atom.entry+xml if new media type is used
+1 to doing this outside of APP (but concerned about deprecating...)
My use case: A web page that
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:
There's absolutely nothing to disclose.
Are you sure about that?
I just prefer to limit my
material contributions to various standards activities to organizations
whose IP policies have been vetted and approved by my employer's IP
lawyers
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:
John Panzer wrote:
[snip]
+1 to doing this outside of APP (but concerned about deprecating...)
[snip]
An I-D / RFC can update another RFC
I think John should edit.
--
Robert Sayre
* Robert Sayre [EMAIL PROTECTED] [2006-11-30 08:10]:
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:
If y'all think
Ah, this is what's called innappropriately folksy. It's
a common rhetorical device used when the speaker wants to
appear that they're on the side of the common man or
21 matches
Mail list logo
