Subject: Outstanding work on format draft

From: Tim Bray <[email-masked]>
Date: Thu, 17 Mar 2005 13:58:35 -0800

If you check the latest format draft  
(http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-06.txt),  
there are a bunch of open issues marked by the editor with "[[anchor"

We're going to need to sort out some of these before taking this  
forward.  Paul did a run-through, sent it to me, and I've fiddled a  
bit, here are the results.  There are 3 sections:

A. Things that don't require WG discussion but may require editorial  
action
B. Things that don't require any short-term action
C. Things that potentially require WG action

If you have feedback, *PLEASE* don't just reply to this message, the  
subject line isn't helpful.  In particular, if you want to change some  
specific thing about the spec, we must have a separate thread.

======================================================================== 
===

A. Things that don't require WG discussion but may require editorial  
action:

    [[anchor4: Ask yourself: is the example atom:entry valid?]]

No, it's not, because there's no <summary> or <content>; so fix it.

    [[anchor31: J.  Reschke: I'm not sure I understand what
    this is for.  It seems to discourage putting XML data out-of-band.
    Why? ...  Explaining the issue instead of just trying to enforce it
    may lead to better results...]]

Agree that an explanation would be helpful, and it would be nice to  
have it before last call.

======================================================================== 
===

B. Things that don't require any short-term action

    [[anchor7: discussion of white space]]

There were a couple of failed white-space Paces, just take this out.

    [[anchor11: Some feel
    type attributes with different allowable values in different elements
    is confusing.]].

Yep, and they may be right.  Haven't seen any Paces.  It's not fatal,  
take this out.

    [[anchor12: example atom entry w/ escaped markup]]

That should be given in the -07 draft, but can wait until after IETF
last call if it is contentious or a whole lot of work.

    [[anchor21: Substantially changed from format-05, review carefully.]]

Agree. :-)

    [[anchor22: inheritance]]

This is a duplicate of anchor24, so lose it.

    [[anchor45: Substantially changed from format-05, review carefully]]

Agree. :-)

    The "atom:id" element conveys a permanent, universally unique

    [[anchor67: Changed to
    MAY from SHOULD.  Republishers might want to copy it.  --R.  Sayre]]

Hard to argue.

    [[anchor71: update upon publication]]
    [[anchor72: update upon publication]]
    [[anchor73: update upon publication]]

Leave these in to give IANA a hint.

    [[anchor85: This section should be removed before final
    publication.]]

Leave this in to give the RFC Editor a hint.

======================================================================== 
===

C. Things that potentially require WG action:

    [[anchor24: What if
       there's a source-feed element? This is busted.  We should make
       author required for atom:feed and optional for atom:entry.  No
       inheritance co-constraints required.  --R.  Sayre]]

Right, this seems broken on the surface.  Let's get some proposed  
wordings.  On the other hand if we decide to override the editors and  
put <atom:head> back, this goes away (right?)

    [[anchor25: "atom:entry elements MUST NOT
       contain more than one atom:link element with a rel attribute value
       of "alternate" that has the same type attribute value." This
       requirement predates @hreflang.  Keep it? --R.  Sayre]]

Keeping it would be plausible.  So would changing the language to say  
"with the same type and hreflang attribute values."  The default action  
is to leave things as they are, so if you want a change, post  
separately with a wording.

    o  atom:entry elements MUST contain an atom:summary element in any of
       the following cases: [[anchor26: Do these requirements reflect the
       WG's decisions? --R.  Sayre]]
       *  the atom:entry element contains no atom:content element.
          [[anchor27: Net result: Atom entries MUST have an atom:summary
          or an atom:content element.]]
       *  the atom:entry contains an atom:content that has a "src"
          attribute (and is thus empty).
       *  the atom:entry contains content that is encoded in Base64; i.e.
          the "type" attribute of atom:content is a MIME media type
          [RFC2045] and does not begin with "text/" nor end with "+xml".

Yes, this reflects the WG consensus, and yes, the implication is that  
you need either summary or content.  I could live with taking that out  
of Atom, but we need someone to make a formal proposal and build  
consensus.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 17 Mar 2005 15:47:08 -0700

On Thursday, March 17, 2005, at 02:58  PM, Tim Bray wrote:

> "with the same type and hreflang attribute values."  The default 
> action is to leave things as they are, so if you want a change, post 

"...that has the same combination of type and hreflang attribute 
values."

---

From: Graham <[email-masked]>
Date: Thu, 17 Mar 2005 23:46:46 +0000

> There were a couple of failed white-space Paces, just take this out.

I disagree - the Pace I wrote was about whitespace within content, 
whereas that anchor is in a section about document syntax. I know there 
are RSS users who think thinks like rel="  alternate  " are acceptable. 
Some discussion of this would be useful.

> Yep, and they may be right.  Haven't seen any Paces.  It's not fatal, 

A quick bit of rewording would help. Currently it basically says "The 
type attribute may have the values..." three times with three different 
rules. Changing it to "On the summary element, the type atrribute may 
have the values..." stops the spec being apparently self-contradicting.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 17 Mar 2005 19:00:59 -0500

> Some discussion of this would be useful.

Write something down. I can't speak for Mark here, but I have no idea 
what needs to be said there.

> have the values..." stops the spec being apparently self-contradicting.

Excellent suggestion, thanks.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 17 Mar 2005 16:22:49 -0800

On Mar 17, 2005, at 3:46 PM, Graham wrote:

> whereas that anchor is in a section about document syntax. I know 
> there are RSS users who think thinks like rel="  alternate  " are 
> acceptable. Some discussion of this would be useful.

I think I'd claim that the spec as-is rules out <link rel="  alternate 
">, but if it we have experience from the field saying that this is a 
common error, I'd have nothing against having something in the spec to 
head it off.

> type attribute may have the values..." three times with three 
> different rules. Changing it to "On the summary element, the type 
> atrribute may have the values..." stops the spec being apparently 
> self-contradicting.

+1   -Tim

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 18 Mar 2005 08:44:44 +0100 (CET)

> Some discussion of this would be useful.

Refering to http://www.w3.org/TR/REC-xml/#AVNormalize, it seems to me that
rel="  alternate  " should be processed as rel="alternate", because (in my
opinion) the rel attribute should be declared of type NMTOKENS, and not
CDATA.

...maybe just giving a DTD in addition to the RNG schema would be
sufficient...

-- 
Thomas Broyer

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 18 Mar 2005 15:50:05 +0200

> ...maybe just giving a DTD in addition to the RNG schema would be

Not everyone is going to use a DTD even if provided, so providing a DTD 
would cause harm, because parsers would report different things 
depending on the use of the DTD.

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

---

From: Tim Bray <[email-masked]>
Date: Fri, 18 Mar 2005 09:13:22 -0800

On Mar 18, 2005, at 5:50 AM, Henri Sivonen wrote:

> Not everyone is going to use a DTD even if provided, so providing a 
> DTD would cause harm, because parsers would report different things 

+1 on "no DTD". -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Mar 2005 20:35:28 -0800

> what needs to be said there.

I was thinking more of whitespace between elements, rather than that in 
attributes. E.g., "Whitespace in between the children of atom:feed and 
atom:element is not semantically significant."

> Excellent suggestion, thanks.

+1

--
Mark Nottingham     http://www.mnot.net/