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