Subject: Comments on atompub-format-08 (Modified by Tim Bray)

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 12:19:06 -0400

Redirected from John Cowan -Tim
====================================================================

I heard about the Last Call via Ongoing, so I'm going to pester you with
these rather than doing the Right Thing, because at the moment I'm too
swamped to find out what the Right Thing is.  Feel free to squelch any
of these that have been already discussed to death, or to point me to
the Right Thing.

3.2.1:  Allowing only one atom:name in a Person construct is a Bad 
Thing.
Lots of people have different names in different contexts (it's common
for Chinese and Chinese-American people to have distinct Chinese and
English names, e.g.)  Since atom:name is language-sensitive, it should
be repeatable.

4.1.1:  If the order of child elements in an atom:feed element is
meaningless, then it ought to be nailed down by the specification to 
some
fixed arbitrary order (alphabetical or whatever).  Doing that simplifies
processing, eliminates unnecessary differences between semantically
equivalent feed documents, and prevents people from smuggling in 
semantic
information by using some magic ordering of child elements.

4.1.1:  Why require an "alternate" atom:link in an atom:feed?
This implies that a feed can't be the only version of the content:
but conceptually a feed might be completely self-contained, with all
the content right in the feed.  Weaken MUST to SHOULD, I'd say.

4.1.2:  same comment on ordering as 4.1.1.

4.1.3.2:  I have my doubts whether the atom:content@type attribute needs
a SHOULD.  That makes life difficult for people who are repackaging 
other
kinds of feeds or feed-like documents as Atom, because they can't know
the type in the general case without attempting to fetch the content.
Type should be a totally optional hint.

4.1.3.2: The last graf seems totally arbitrary.  What's wrong with
incorporating remote text/plain, text/html, or */*-xml documents by
reference?  In particular, what if they don't yet exist when the feed
is created?  This graf should be removed.

4.2.6 (editorial):  for "SHOULD ... should" read "SHOULD ... SHOULD".

4.2.9 (editorial):  The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove "is an empty element that".

--
John Cowan  [email-masked]  www.reutershealth.com  
www.ccil.org/~cowan
No man is an island, entire of itself; every man is a piece of the
continent, a part of the main.  If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friends or of thine own were: any man's death diminishes 
me,
because I am involved in mankind, and therefore never send to know for
whom the bell tolls; it tolls for thee.  --John Donne

---

From: Norman Walsh <[email-masked]>
Date: Fri, 22 Apr 2005 14:28:35 -0400

FWIW.

/ John Cowan <[email-masked]> was heard to say:
| 3.2.1:  Allowing only one atom:name in a Person construct is a Bad
| Thing.
| Lots of people have different names in different contexts (it's common
| for Chinese and Chinese-American people to have distinct Chinese and
| English names, e.g.)  Since atom:name is language-sensitive, it should
| be repeatable.

Yeah, repeatable and the UI picks one seems reasonable to me.

| 4.1.1:  If the order of child elements in an atom:feed element is
| meaningless, then it ought to be nailed down by the specification to
| some
| fixed arbitrary order (alphabetical or whatever).  Doing that simplifies
| processing, eliminates unnecessary differences between semantically
| equivalent feed documents, and prevents people from smuggling in
| semantic
| information by using some magic ordering of child elements.

*shrug* I seem to recall lots of discussion about this. I'm inclined
to agree with John, but I can live with the status quo.

| 4.1.1:  Why require an "alternate" atom:link in an atom:feed?
| This implies that a feed can't be the only version of the content:
| but conceptually a feed might be completely self-contained, with all
| the content right in the feed.  Weaken MUST to SHOULD, I'd say.

Indeed. But we've gone round and round on this too.

| 4.1.3.2: The last graf seems totally arbitrary.  What's wrong with
| incorporating remote text/plain, text/html, or */*-xml documents by
| reference?  In particular, what if they don't yet exist when the feed
| is created?  This graf should be removed.

I agree.

| 4.2.9 (editorial):  The atom:link element is explicitly described as
| empty, which violates the rules in 6 for foreign element extension.
| Remove "is an empty element that".

Yep.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Almost every man wastes part of his
http://nwalsh.com/            | life in attempts to display qualities
                              | which he does not possess, and to gain
                              | applause which he cannot keep.--Dr.
                              | Johnson

---

From: Henri Sivonen <[email-masked]>
Date: Sat, 23 Apr 2005 00:17:24 +0300

> Yeah, repeatable and the UI picks one seems reasonable to me.

IMO, it is not reasonable, because it would complicate clients for 
virtually no practical benefit.

If only one name is displayed, why bother with all the hassle for the 
special case instead of the author deciding which name (s)he feels like 
using today? If you've got an English name and a Chinese name, use the 
Chinese name if you are writing Chinese and the English name if you are 
writing English.

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