Some editoria of the '09 specification

It's a good while since I've read through  
draft-ietf-atompub-protocol-09.txt and even longer since I've been an  
active member of this working group. I'm sorry for rushing in this late,  
but I'll try to not stir things up too much. :-)

I have a few not too complicated comments about the 09 draft, which goes  
like this:

  7.2.3.2 The "href" Attribute

  The app:collection element MUST contain a "href" attribute, whose
  value gives the IRI of the collection.

  ->

  The app:collection element MUST contain an "href" attribute, whose
  value gives the IRI of the collection.

'a' should be 'an'.


  8.1 Creating resource with POST

  [...] , for example by changing the content of the "id" element.
  returning the entry [...]

  ->

  [...] , for example by changing the content of the "id" element.
  Returning the entry [...]

capital 'R' in 'Returning'.


  8.2 Example

The 'Content-Type' header misses a 'charset' parameter and there's a weird  
space after the dashes of all headers.

  [...] In particular, the publishing system in this example filled
  in some values not provided in the original POST. [...]

Nothing wrong here, but I do wonder where the publishing system gathered  
the filename of the entry from.


  8.4.1 Title: Header

Can we utilize the Content-Description header the same way to populate the  
atom:summary element?


  8.5 Editing Entries with Foreign Markup

  To avoid unintentional loss of data when editing entries or media
  link entries, Atom Protocol clients SHOULD preserve all metadata,
  including unknown foreign markup as defined in Section 6 of
  [RFC4287], which has not been intentionally modified.

The last sentence here is a bit malplaced imo. I think this is better:

  To avoid unintentional loss of data when editing entries or media
  link endries, Atom Protocol clients SHOULD preserve all metadata
  that has not been intentionally modified, including foreign markup
  as defined in Section 6 of [RFC4287].


  9.1 Collection Paging

  [...]  Instead, the Atom feed document MAY contain [...]

  ->

  [...]  Instead, the Atom Feed Document MAY contain [...]

Consistency with the rest of the specification dictates that the first  
letter of all named atom resources should be uppercase.


That's all I had for now. Thank you for reading. :-)

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