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
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
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
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
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
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
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
