Re: Atom Entry Documents
Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1 IMO, new optional type parameters make more sense. Judy- On 12/10/06, James M Snell [EMAIL PROTECTED] wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D this week. Please let me know which of the two approaches below y'all prefer... Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed Option B) New Entry media type application/atom.entry+xml - James
Re: PaceEntryMediatype
Thomas Broyer wrote:
snip
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type
=entry = entry
/snip
+1
On 11/29/06, Thomas Broyer [EMAIL PROTECTED] wrote:
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 (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type=entry = entry
{{{
Atom Entry Documents are identified with the
application/atomentry+xml media type (See section 15).
}}}
How about defining a tree similar to the */vnd.* one?
- application/atom+xml = feed or entry document
- application/atom.categories+xml = category document
- application/atom.service+xml = service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml = entry document
As for Tim's concerns, I'd also prefer having it done outside the APP.
Also, the APP draft would need to be updated to remove the entry
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)
--
Thomas Broyer
Re: [atom-syntax] [RFC 4685] uri in xml namespace
James wrote:[snip]have it direct to a summary page like the XHTML[snip]+1 Judy-namespaceOn 11/9/06, James M Snell [EMAIL PROTECTED] wrote:I've updated the purl registration so that it redirects to the RFC.I can, alternatively, have it direct to a summary page like the XHTMLnamespace does if that's what folks would prefer.- JamesJudy Piper wrote: I think that has been understood; I believe that James will be addressing this namespace issue. Judy- [snip]
Re: [atom-syntax] [RFC 4685] uri in xml namespace
I think that has been understood; I believe that James will be addressing this namespace issue.Judy-On 11/9/06, Asbjørn Ulsberg [EMAIL PROTECTED] wrote:On Sun, 05 Nov 2006 06:47:23 +0100, Judy Piper [EMAIL PROTECTED]wrote: I was expecting a Namespace document that explains the namespace URI itself and the relationship between the spec and the URI.Am I wrong to expect this behavior?What is to be expected when resolving a namespace URI is undefined, but acommon solution is to have a document explaining what the URI means andhow the vocabulary residing in that namespace can be used. In other words; just as you say. Redirecting directly to the specification works, but aninformative and perhaps more human friendly document inbetween wouldindeed be nice.A good example is the XHTML namespace URI: http://www.w3.org/1999/xhtml--Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/«He's a loathsome offensive brute, yet I can't look away»
Re: [atom-syntax] [RFC 4685] uri in xml namespace
Yup. On 11/5/06, Nicolas Krebs [EMAIL PROTECTED] wrote: Date: Sun, 5 Nov 2006 00:47:23 -0500From: Judy Piper [EMAIL PROTECTED]To: James M Snell [EMAIL PROTECTED]Subject: Re: [atom-syntax] [RFC 4685] uri in xml namespaceCC: Nicolas Krebs [EMAIL PROTECTED], atom-syntax@imc.org( http://purl.org/syndication/thread/1.0 redirecting to http://www.ietf.org/rfc/rfc4685.txt )I was expecting a Namespace document that explains the namespace URI itselfand the relationship between the spec and the URI.Am I wrong to expectthis behavior? Such in http://www.w3.org/2005/Atom ?
