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 any type of content in atom:content? (For example, relative SVG > 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. > > > # 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 somewhere. > * 3.1.1 The "type" Attribute > > 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. > * 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. No, that's broken. There can be no expectation of interoperability. > 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. > > * 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. 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. > * 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. No. It used to be "atom:feed elements MAY contain exactly one atom:icon element, but MUST NOT contain more than one." etc, etc. > > * 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 suppose you could. Your likes and dislikes aren't relevant right now, btw. > * 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? John Cowan raised this issue in last call, the appropriate time, and the chairs agreed there was no consensus to keep the SHOULD. > Are feed readers supposed to be able to render Atom documents within > atom:content? This is theoretically possible at the moment. Great. > > # 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'? There is nothing in the spec to support that conclusion, and the spec can never define handling for every media type under the sun. > * 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 happens. > * 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.) Nope. Too late. bye, Robert Sayre
