Subject: some small comments on 08

From: Anne van Kesteren <[email-masked]>
Date: Sun, 22 May 2005 11:22:24 +0200

* 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. XLinks, et cetera.)

# 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/?

* 3.1.1 The "type" Attribute

Are the values it can take case-sensitive or case-insensitive?

* 3.1.1.1 Text

# If the value is "text", the content of the Text construct MUST NOT
# contain child elements. Such text is intended to be presented to
# humans in a readable fashion. Thus, Atom Processors MAY collapse
# white-space (including line-breaks), and display the text using
# typographic techniques such as justification and proportional fonts.

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.

For white-space significance text I need to use 'html' or 'xhtml'
instead using PRE or xhtml:pre?

* 3.1.1.3 XHTML

I know this has been discussed before but the required DIV makes it more
trivial to use type 'html' instead.

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, XHTML
Basic, HTML5 (Web Applications 1.0). (Web Forms 2.0 extends XHTML 1...)
Et cetera.

* 4.1.1 The "atom:feed" Element

I wonder why different phrases are chosen here. Examples:

1. atom:feed elements MUST contain exactly one atom:author element
2. atom:feed elements MUST NOT contain more than one atom:icon element.

Can't we make the second:

# atom:feed elements MAY contain exactly one atom:icon element.

* 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.)

* 4.1.3.2 The "src" attribute

Shouldn't it be subtype that ends in '+xml'? Also, I'm not really sure
why it is useful to say that it SHOULD be local. What if I want to show
a SVG graphic? Perhaps we can exclude 'image' from type?

Are feed readers supposed to be able to render Atom documents within
atom:content? This is theoretically possible at the moment.

# If the value of "type" begins with "text/" (case-insensitive), the
# content of atom:content MUST NOT contain child elements.

This means basically text/xml is out? Sounds like a good idea. What
happens with text/html? Are authors expected to apply the same rules as
with 'html'?

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

* Links

I don't understand why we have so many different link constructs.
<atom:link href="iri"/>, <atom:image>iri</atom:image>,
<atom:uri>iri</atom:uri>, <atom:content src="iri"/>.

Can't we name them consistently? I'd suggest 'href' or 'url'. ('url' is
used in CSS and extensions of HTML and XHTML 1 made by the WHATWG.)

-- 
Anne van Kesteren
<http://annevankesteren.nl/>

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 14:47:05 -0400

> references. XLinks, et cetera.)

This issue was brought up during last call (yes, during, not after :),
and Tim suggested text covering the issue:
http://www.imc.org/atom-syntax/mail-archive/msg14400.html

The WG has never intended anything else (AFAIK), so I think its safe
for the editors to make this change.

> # element and its children.

Someone speak up if there's a preference out there somewhere.

> Are the values it can take case-sensitive or case-insensitive?

MIME types are case insensitive. The draft specifies only lowercase
values in addition to those.

> don't.) This question also applies to the next section.

No, that's broken. There can be no expectation of interoperability.

> 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 been debated by Graham, Paul, Martin,
etc. Feel free to try and explain this again if I don't get it.

> Basic, HTML5 (Web Applications 1.0). (Web Forms 2.0 extends XHTML 1...)

We reference XHTML modularization. We can't say anything about 'valid'
because we don't have a DTD. I don't feel there is any value in
exploring this issue at a deeper level. We could, but it's not like it
would matter to implementors. Pointless legislation, if you will.

> # atom:feed elements MAY contain exactly one atom:icon element.

No. It used to be "atom:feed elements MAY contain exactly one
atom:icon element, but MUST NOT contain more than one." etc, etc.

> really dislike this combined construct by the way.)

I suppose you could. Your likes and dislikes aren't relevant right now, btw.

> a SVG graphic? Perhaps we can exclude 'image' from type?

John Cowan raised this issue in last call, the appropriate time, and
the chairs agreed there was no consensus to keep the SHOULD.

> atom:content? This is theoretically possible at the moment.

Great.

> happens with text/html? Are authors expected to apply the same rules as

There is nothing in the spec to support that conclusion, and the spec
can never define handling for every media type under the sun.

> i18n and prevents people from defining the expansion of an abbreviation,

Minor flaw. It happens.

> used in CSS and extensions of HTML and XHTML 1 made by the WHATWG.)

Nope. Too late.

bye,

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 19:55:24 +0100

> really dislike this combined construct by the way.)

You can, but you would have to embed a full XHTML document, including
<html> and <body> elements. Also I'd suspect that the document might
not get treated as well by implementations and stuck in an IFRAME or
something.

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Sun, 22 May 2005 12:03:36 -0700

> Someone speak up if there's a preference out there somewhere.

"descendents" is more accurate. --Tim

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 02:42:03 +0200

* Anne van Kesteren <[email-masked]> [2005-05-22 11:35]:
> 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 symmetry here: with @type="xml", you have to
enclose a full XML document, which will always have a root
element. The pseudo-XHTML DIV required for @type="xhtml" makes
XHTML fragments behave the same way.

I don’t know if I like it. I don’t know if it’s a good solution.
But it is consistent on some level, at least.

Regards,
-- 
Aristotle

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 05:30:58 +0200

* Anne van Kesteren <[email-masked]> [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, XHTML Basic, HTML5 (Web Applications
> 1.0). (Web Forms 2.0 extends XHTML 1...) Et cetera.

I vote for punting the validity issue. I don’t think we can
reasonably enforce any stronger restriction that requiring
well-formedness here. Browsers which understand
application/xhtml+xml behave that way, FWIW.

It’s probably best to tell people that they are likely to get
inconsistent results at best if they try to stick a frameset
document or something equally silly in their feed, but not to
prohibit them from doing so.

We can’t anticipate what direction XHTML will take.

> Why is significant information hidden in attributes? That is
> bad for i18n and prevents people from defining the expansion of
> an abbreviation, for example.

Struck me as odd as well.

> * Links
> 
> I don't understand why we have so many different link
> constructs. <atom:link href="iri"/>,
> <atom:image>iri</atom:image>, <atom:uri>iri</atom:uri>,
> <atom:content src="iri"/>.
> 
> Can't we name them consistently? I'd suggest 'href' or 'url'.
> ('url' is used in CSS and extensions of HTML and XHTML 1 made
> by the WHATWG.)

+1

I’m pretty sure that the latter two changes are not
possible/permissible at this stage of the process, though.

Regards,
-- 
Aristotle

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 23 May 2005 08:54:32 +0200

Robert Sayre wrote:
>> define that for interoperability. (See HTML for what happens when
>> you don't.) This question also applies to the next section.
> 

I think there should be. Authors will try to do it anyway and defined 
error handling is better than reverse engineering the market leader's 
error handling.

> etc. Feel free to try and explain this again if I don't get it.

White-space may be collapsed inside 'text' as currently defined.

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

I think you are rushing things too fast. It would be much better if we
fixed this.

>> ('url' is used in CSS and extensions of HTML and XHTML 1 made by
>> the WHATWG.)
> 
> Nope. Too late.

And this.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 10:26:32 +0200

* Anne van Kesteren <[email-masked]> [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 been debated by
> >Graham, Paul, Martin, etc. Feel free to try and explain this
> >again if I don't get it.
> 

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 about that, though.

Regards,
-- 
Aristotle

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 23 May 2005 10:28:27 +0200

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 explicit
> about that, though.

However, text/plain is not allowed everywhere where 'text' is allowed.

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 23 May 2005 10:45:05 +0200 (CEST)

> There is some symmetry here: with @type="xml", you have to

Which @type="xml"? Did you mean @type="text/xml"?

> XHTML fragments behave the same way.

With the difference that this div is not part of the content.

> But it is consistent on some level, at least.

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]

[1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html

-- 
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 11:35:56 +0200

> Which @type="xml"? Did you mean @type="text/xml"?

Sorry, I meant any XML media type.

> > element. The pseudo-XHTML DIV required for @type="xhtml"
> > makes XHTML fragments behave the same way.
> 

Ah! Good catch.

> > I don’t know if I like it. I don’t know if it’s a good
> > solution. But it is consistent on some level, at least.
> 
> It is not, not at all.
> 
> To everyone here: please, comment on PaceOptionalXhtmlDiv,
> either +1 or -1, but at least argument.

I was leaning +1 and almost voted that way when you posted the
Pace, but I was not sure if I had enough of the picture so I
abstained at the time. I’m still not firmly convinced (and
intermittently thought maybe it was not so bad to keep the DIV,
see above), but I’m still don’t see that it really is necessary.

In particular, I don’t see why mandating the pseudo-XHTML DIV is
a better solution than promoting correct implementation by way of
good examples, which you argued in that thread as well.

So +1, absent an overwhelming example that people are more likely
to get their namespaces wrong than right.

Regards,
-- 
Aristotle

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 May 2005 11:31:30 +0200

Thomas Broyer wrote:
 > ...

For the record: I am +1 on 
<http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv>.

Best regards, Julian

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 11:41:45 +0200

* Anne van Kesteren <[email-masked]> [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 explicit about that, though.
> 

True. But it seems reasonable to tell people they shouldn’t stick
content with significant linebreaks and whitespace into their
titles? Not that I have any strong position about this; it just
seems to make sense.

Regards,
-- 
Aristotle

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 May 2005 07:40:57 -0400

> error handling is better than reverse engineering the market leader's

There is no consensus for me to record, AFAIK.

> I think you are rushing things too fast. It would be much better if we

I would never describe this process as "too fast". I happen to agree
with you here, but I don't think the "problem" you've found is
important. Maybe other folks will. *shrugs

wrt the atom:uri element, you're ignoring an incredibly unproductive
thread that already occurred on this topic. I want you to recite the
Atompub Web Address Oath of Silence:

"I hereby promise that should I ever again be tempted to raise an
issue around the naming of web addresses, I shall strike myself firmly
on the head with a heavy blunt object until I come to my senses."[0]

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg13865.html

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 24 May 2005 11:40:33 +0300

> <http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv>.

+1 from me too.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 10:16:27 +0100

On 24 May 2005, at 9:40 am, Henri Sivonen wrote:

>> For the record: I am +1 on <http://www.intertwingly.net/wiki/pie/ 
>> PaceOptionalXhtmlDiv>.

-1, and additionally I don't think the Pace is even complete or  
reliably implementable.

Graham

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 10:16:27 +0100

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 24 May 2005 15:11:51 +0200

> I think you are rushing things too fast. It would be much better if we

I agree.

>>>  Can't we name them consistently? I'd suggest 'href' or 'url'.

+2.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 24 May 2005 15:14:08 +0200 (CEST)

> -1, and additionally I don't think the Pace is even complete or

FYI, it is not, and I already explained in which extent (first, I forgot
to say in the Pace that the same would apply for atom:content with
type="xhtml"), that's why I pointed to a mail with some more explanation
[1]. I was told not to edit the Pace to reflect it, so...

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 24 May 2005 15:36:36 +0200 (CEST)

Asbjørn Ulsberg wrote:
> On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote:
>>>> i18n and prevents people from defining the expansion of an

+1, drop the "label" attribute and make its value a child of the
atom:category element.

Some more wording would also be needed to explain the exact role of the
"term" attribute. Couldn't its value default to the "label" when not
present (this imply making it optional)?

>>>>  Can't we name them consistently? I'd suggest 'href' or 'url'.

I have no opinion about atom:uri, it seems find to me but I'm not attached
to it.

@href gives an Hypertext REFerence to another, related, resource
(alternate, related, self, feed, etc.), so -1 to changing its name.

@src tells the Atom Processor where the content of the entry is located. I
wouldn't be opposed to "href" in this case, but nothing else than "href"
or "src".

Other listed examples were about attribute vs. text node, I'm +0.5 to
moving text nodes into attributes (in atom:logo and atom:icon)

These are also common usages in many XML dialects (XHTML, XInclude, XLink,
SVG, etc.) Many of these tend to use XLink when linking to or embedding
external resources, so using XLink wouldn't bother me either (hey, some
are talking about replacing atom:author|atom:contributor with Dublin Core,
so why not?)

-- 
Thomas Broyer

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 24 May 2005 15:41:14 +0200 (CEST)

Thomas Broyer wrote:
> 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
   div element; if we go for a SHOULD or MAY on discarding the div elements,
   it is even *more* reliably implementable.

-- 
Thomas Broyer

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 24 May 2005 15:01:48 +0100

>    it is even *more* reliably implementable.

We had a discussion about optional div not so long ago, and I came away 
unconvinced then. Can you present some arguments to back those opinions up?

cheers
Bill

---

From: Graham <[email-masked]>
Date: Wed, 25 May 2005 12:08:36 +0100

>    it is even *more* reliably implementable.

With the current draft, everyone wraps their content, in a single  
div, and everyone at the other end removes it, producing exactly the  
same XHTML, always.

With the Pace, try transporting this:
  <div>Text</div>

Wrap it in a div:
  <atom:content><div><div><Text/div></div></atom:content>

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 appear in the same form,  
regardless of what I type, or whether Thomas Broyer thinks the change  
didn't matter.

Graham

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 26 May 2005 08:40:32 +0200 (CEST)

Graham wrote:
> 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 appear in the same form,

With the current (08) draft, try transporting this textual summary:
This deals with
 - feeding cats
 - feeding dogs
 - feeding fishes

Put it in atom:summary:
<atom:summary type="text">
This deals with
 - feeding cats
 - feeding dogs
 - feeding fishes
</atom:summary>

Decode:
This deals with - feeding cats - feeding dogs - feeding fishes

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 appear in the same form,
regardless of what I type, or whether [someone] thinks the change
didn't matter.

It all depends what you expect from atom:content with "special" @type
values and Text Constructs:
 - transport textual data, eventually enriched with some markup
 - transport data (which happen to be textual) without modifying it in any
way

I think Atom should be homogeneous as to how it deals with this: allow
"insignificant" changes, as long as the text has the same meaning. In the
same way we define whitespace collapsing for @type="text"; we could define
"dummy div discarding" for type="xhtml".

-- 
Thomas Broyer

---

From: Graham <[email-masked]>
Date: Thu, 26 May 2005 12:07:51 +0100

> This deals with - feeding cats - feeding dogs - feeding fishes

That's not decoding, that's display. There's nothing in the Atom spec  
that says the line breaks need to be (or even can be) removed from  
the actual data, it just says you don't need to display them to the  
end user. The body of the message is preserved end-to-end.

Graham