Re: some small comments on 08

On 26 May 2005, at 7:40 am, Thomas Broyer wrote: With the current (08) draft, try transporting this textual summary: This deals with - feeding cats - feeding dogs - feeding fishes Put it in atom:summary: This deals with - feeding cats - feeding dogs - feeding fishes Decode: This deals

Re: some small comments on 08

Graham wrote: > With the Pace, try transporting this: > Text > > Wrap it in a div: > > > Decode it: > Text > > Oops, we've thrown data away. Whether the change is significant or not > isn't important. As a user, I expect to be able to type something in > at one end and have it reliably

Re: some small comments on 08

Thomas Broyer wrote: Bill de hÓra wrote: Thomas Broyer wrote: * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. We had a discussion about optional

Re: some small comments on 08

On 24 May 2005, at 2:41 pm, Thomas Broyer wrote: Oops, before it'd be misinterpreted: * the Pace is not *complete* * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more*

Re: some small comments on 08

Bill de hÓra wrote: > Thomas Broyer wrote: >> * it is not less reliably implementable than the current draft's >>mandatory div element; if we go for a SHOULD or MAY on discarding >> the div elements, it is even *more* reliably implementable. > > We had a discussion about optional div not so l

Re: some small comments on 08

Thomas Broyer wrote: * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. We had a discussion about optional div not so long ago, and I came away u

Re: some small comments on 08

Thomas Broyer wrote: > Graham wrote: >> -1, and additionally I don't think the Pace is even complete or >> reliably implementable. > > FYI, it is not, Oops, before it'd be misinterpreted: * the Pace is not *complete* * it is not less reliably implementable than the current draft's mandatory

Re: some small comments on 08

Asbjørn Ulsberg wrote: > On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote: * 4.2.2 The "atom:category" Element Why is significant information hidden in attributes? That is bad for i18n and prevents people from defining the expansion of an abbreviation, for example.

Re: some small comments on 08

Graham wrote: > On 24 May 2005, at 9:40 am, Henri Sivonen wrote: >> On May 23, 2005, at 12:31, Julian Reschke wrote: >>> For the record: I am +1 on >> PaceOptionalXhtmlDiv>. > > -1, and additionally I don't think the Pace is even complete or > reliably impl

Re: some small comments on 08

On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: * 4.2.2 The "atom:category" Element Why is significant information hidden in attributes? That is bad for i18n and prevents people from defining the expansion of an abbreviation, for example. Minor flaw. It ha

Re: some small comments on 08

On 24 May 2005, at 9:40 am, Henri Sivonen wrote: On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on . -1, and additionally I don't think the Pace is even complete or reliably implementable. Graham

Re: some small comments on 08

On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on . +1 from me too. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/

Re: some small comments on 08

On 5/23/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > Robert Sayre wrote: > >> What happens when it does contain child elements? I think we should > >> define that for interoperability. (See HTML for what happens when > >> you don't.) This question also applies to the next section. > > > > No

Re: some small comments on 08

* Anne van Kesteren <[EMAIL PROTECTED]> [2005-05-23 10:35]: > A. Pagaltzis wrote: > >Last I asked, I understood that whitespace would be preserved > >if you supply 'text/plain' content; @type='text' is more like > >inline text in an XML document (or in HTML). Maybe the spec > >could be more explic

Re: some small comments on 08

Thomas Broyer wrote: It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. See also further explanation and technical arguments in "Consensus call on last raft of issues" [1] > ... For the record: I am +1 on

Re: some small comments on 08

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-23 10:50]: > A. Pagaltzis wrote: > > There is some symmetry here: with @type="xml", you have to > > Which @type="xml"? Did you mean @type="text/xml"? Sorry, I meant any XML media type. > > enclose a full XML document, which will always have a root >

Re: some small comments on 08

A. Pagaltzis wrote: > > * Anne van Kesteren <[EMAIL PROTECTED]> [2005-05-22 11:35]: >> * 4.1.3.1 The "type" attribute >> >> Can I circumvent the DIV element by using the media type of >> XHTML? (I really dislike this combined construct by the way.) > > I used to find it extremely horrible. Now I’

Re: some small comments on 08

A. Pagaltzis wrote: White-space may be collapsed inside 'text' as currently defined. Last I asked, I understood that whitespace would be preserved if you supply 'text/plain' content; @type='text' is more like inline text in an XML document (or in HTML). Maybe the spec could be more explicit ab

Re: some small comments on 08

* Anne van Kesteren <[EMAIL PROTECTED]> [2005-05-23 09:05]: > Robert Sayre wrote: > >>For white-space significance text I need to use 'html' or > >>'xhtml' instead using PRE or xhtml:pre? > > > >I don't understand what you're saying here, but I'm pretty > >sure every possible whitespace issue has

Re: some small comments on 08

Robert Sayre wrote: What happens when it does contain child elements? I think we should define that for interoperability. (See HTML for what happens when you don't.) This question also applies to the next section. No, that's broken. There can be no expectation of interoperability. I think th

Re: some small comments on 08

* Anne van Kesteren <[EMAIL PROTECTED]> [2005-05-22 11:35]: > * 3.1.1.3 XHTML > > I would like to see "valid XHTML" more clearly defined. There > are a lot of different XHTML versions I know of and some might > not include a DIV element at all... You have XHTML 1 (in three > versions), XHTML 1.1,

Re: some small comments on 08

* Anne van Kesteren <[EMAIL PROTECTED]> [2005-05-22 11:35]: > * 4.1.3.1 The "type" attribute > > Can I circumvent the DIV element by using the media type of > XHTML? (I really dislike this combined construct by the way.) I used to find it extremely horrible. Now I’m not sure. There is some symm

Re: some small comments on 08

On May 22, 2005, at 11:47 AM, Robert Sayre wrote: # Any element defined by this specification MAY have an xml:lang # attribute, whose content indicates the natural language for the # element and its children. s/children/descendents/? Someone speak up if there's a preference out there somewhe

Re: some small comments on 08

Sunday, May 22, 2005, 10:22:24 AM, you wrote: > * 4.1.3.1 The "type" attribute > Can I circumvent the DIV element by using the media type of XHTML? (I > really dislike this combined construct by the way.) You can, but you would have to embed a full XHTML document, including and elements. Als

Re: some small comments on 08

On 5/22/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > > * 2. Atom Documents > > # This includes such elements and attributes as specified by Atom > # itself, as well as those specified by extensions to Atom. > > Doesn't this also apply to HTML and XHTML content when applicable? And > to an

some small comments on 08

* 2. Atom Documents # This includes such elements and attributes as specified by Atom # itself, as well as those specified by extensions to Atom. Doesn't this also apply to HTML and XHTML content when applicable? And to any type of content in atom:content? (For example, relative SVG references.