Re: Obs on format-05

2005-01-31 Thread Antone Roundy
On Sunday, January 30, 2005, at 10:25 AM, Tim Bray wrote: ** @type ** The passages in 3.1.1 and 4.15.1 and 4.6.3 around @type are not consistent. In 3.1.1 media types are not an option: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] in 4.15.1

Re: Obs on format-05

2005-01-31 Thread Bill de hÓra
Robert Sayre wrote: Agree. -1. Bill needs a private content model. Removing the content model from Atom will not fix that. I suggest something like "text/bill+xml". Making general-purpose feeds available where one consumer will only ever use half of the content is bad practice. Use two resource

Re: Obs on format-05

2005-01-30 Thread Mark Nottingham
Hey Bill, Thanks for the detailed, well-justified and precise comments; this is a very helpful format to submit them in (hint, hint). Some selective feedback; On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: Replace: [[[ Note that the choice of any namespace prefix is arbitrary and not semantic

Re: Obs on format-05

2005-01-30 Thread Bill de hÓra
Sam Ruby wrote: Bill de hÓra wrote: reason: we don't need to tell people what they can do with TEXT once we tell them what it is. Often times the use of MAY is advisory to the producer. This is one of those cases: if you are expecting mono spaced fonts, you might want to consider using either

Re: Obs on format-05

2005-01-30 Thread Bill de hÓra
Tim Bray wrote: On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: In 3.1.1 media types are not an option: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] I'm definitely -1 on losing 3.1.1, the text construct is a hard-won compromise and seems to ca

Re: Obs on format-05

2005-01-30 Thread Tim Bray
On Jan 30, 2005, at 9:12 AM, Sam Ruby wrote: I realize that you indicate that you intend to write a Pace on this. Just be aware that earlier drafts of Atom supported multiple content, and a lot of people seemed very motivated to eliminate this. To be fair, it was the original "multipart/alternati

Re: Obs on format-05

2005-01-30 Thread Robert Sayre
Tim Bray wrote: On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: ** 4.15 The "atom:content" [[[ atom:entry elements MUST contain zero or one atom:content elements. ]]] proposal: I would like this loosened to zero or more (a Pace is forthcoming). I have use cases to ship content about in Irish and

Re: Obs on format-05

2005-01-30 Thread Tim Bray
On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: Here are some detailed obs on reading the latest draft. Excellent, Bill, thanks. ** 1. Introduction I don't think further discussion on motivation or principles is needed; on that basis the "[[more motivation/design principles]]" memo could be stru

Re: Obs on format-05

2005-01-30 Thread Sam Ruby
Bill de hÓra wrote: [snip] Lots of good comments. Many are editorial, and can simply be adopted by the editors without an explicit proposal, and for others you indicated that a Pace is forthcoming. I'll comment on a few that I believe require a Pace... ** 3.1.1 "type" Attribute Replace: [[[ I

Re: Obs on format-05

2005-01-30 Thread Anne van Kesteren
Bill de hÃra wrote: ** @type ** The passages in 3.1.1 and 4.15.1 and 4.6.3 around @type are not consistent. In 3.1.1 media types are not an option: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] in 4.15.1 and 4.6.3 they are stated as an option

Obs on format-05

2005-01-30 Thread Bill de hÓra
Hi editors, My overall impression of 05 is positive. Once extensibility and security are tied down, I think we're close to ready to remove the "do no deploy" constriction and let the world have at. Here are some detailed obs on reading the latest draft. ** 1. Introduction I don't think further d