Subject: Re: I-D ACTION:draft-ietf-atompub-format-00.txt

From: Ryan Tomayko <[email-masked]>
Date: Fri, 9 Jul 2004 15:45:25 -0400

Where might one find the XML representation of these documents?

Thanks,
Ryan

On Fri, 09 Jul 2004 15:23:24 -0400, [email-masked]
<[email-masked]> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.
> 
>         Title           : The Atom Syndication Format
>         Author(s)       : M. Nottingham
>         Filename        : draft-ietf-atompub-format-00.txt
>         Pages           : 19
>         Date            : 2004-7-9
> 
> This specification describes Atom, an XML-based Web content and
>    metadata syndication format.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-atompub-format-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-atompub-format-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
>

---

From: [email-masked]
Date: Fri, 09 Jul 2004 15:23:24 -0400

Send a message to:
	[email-masked].
In the body type:

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 9 Jul 2004 16:33:59 -0400

> Where might one find the XML representation of these documents?

With the lawyerly statement up front that 
*Only the .TXT versions served from 
http://www.ietf.org/internet-drafts are normative* :)

The .xml and .html versions of the protocol
can be viewed here along with an HTML
file that gives a color side-by-side diff
between the last version and the latest version:

http://bitworking.org/projects/atom/

   Thanks,
   -joe

---

From: Ryan Tomayko <[email-masked]>
Date: Fri, 9 Jul 2004 16:45:33 -0400

you rock.

---

From: Norman Walsh <[email-masked]>
Date: Fri, 09 Jul 2004 17:19:37 -0400

I find I'm having difficulty keeping up with the volume of traffic on
this list and with the Wiki as a development medium for the spec. But
I will try to carefully read the drafts as they are published.

[...]
|    Therefore, when this specification uses the term "element," it is
|    refering to an Element Information Item in Infoset terms.  Likewise,
|    when it uses the term "attribute," it is refering to an Attribute
|    Information Item.

What about entity, document, etc.? Are those words shorthand as well?

| 2.  Atom Documents
| 
|    An Atom document

Am I to assume document information item here?

|    is an XML document whose document element is the
|    atom:feed element, as described below.
| 
|    Atom documents are specified in terms of the XML Information Set,
|    serialised as XML 1.0 and identified with the "application/atom+xml"
|    media type.

I find the mention of the serialization format here a bit odd. If the
spec is going to describe things in terms of the infoset, then the
serialization form is irrelevant. If the spec wants to mandate a
serialization form, that's fine too, but I don't think it should do
that without justification.

|    Atom documents SHOULD NOT contain Processing Instructions, unless

Why not? And what's the value of saying "should not" anyway. The spec
goes on to say that comments are allowed, but provides no semantics
for them. Why can't we just say PIs are allowed but provide no
semantics for them.

|    All elements and attributes in an Atom document MUST be
|    namespace-qualified.

Does this apply only to top-level elements in an atom:feed or
atom:entry element? If I want to ship around a content constructor
containing DocBook V4.3 content (which has no namespace), I'm allowed
to, aren't I?

|    [RFC3066].  When determining element content's natural language, the
|    first xml:lang attribute encountered in that element's ancestors MUST
|    be used.

"...encountered on that element or the first of its ancestors..." or
words to that effect. "Ancestor" can be construed to not include the
current element.

|    the author.  It MAY be the name of a corporation or other entity no
                                                                     ^ when?
|    individual authors can be named.  Person constructs MUST contain

| 3.2.2  "atom:url" Element

Can we call this atom:uri? It looks really odd to say "atom:url, the
URI that..."

|    The "rel" attribute indicates the type of relationship that the link
|    represents.  Link constructs MUST have a rel attribute, whose value
|    MUST be a string, and MUST be one of the values enumerated in the
|    Atom Protocol specification [Atom-protocol].

Please duplicate that list here. I don't care about the protocol and it's
tedious to go read another spec just for a flat list.

|    link.  Link constructs MAY have a title attribute, whose value MUST
|    be a string.

"MUST be a string"? How can an attribute *not* be a string. Does this
add anything?

| 4.  The "atom:feed" Element
| 
|    The "atom:feed" element is the document (i.e., top-level) element of
|    the format described by this specification.  Its children are a
|    (potentially partial) representation of the state of the feed.
| 
|    The atom:feed element MAY contain any namespace-qualified
|    [W3C.REC-xml-names-19990114] elements as children.  Ordering of the
|    element children of atom:feed element MUST NOT be considered
|    significant.

May it contain (non-whitespace) character information item children? I
assume not, but it doesn't say.

| 4.3  "atom:title" Element
| 
|    The "atom:title" element is a Content construct that conveys a

It seems slightly odd to me that the title is a Content construct. I think
I'd be happier if the title was a string.

| 4.11  "atom:info" Element
| 
|    The "atom:info" element is a Content construct that conveys a
|    human-readable explanation of the feed format itself.  atom:feed
|    elements MAY contain an atom:info element, but MUST NOT contain more
|    than one.
| 
|    The atom:info element SHOULD NOT considered meaningful by processors;
|    it is a convenience to publishers in certain situations.

If it's not meaningful to processors and may be a convenience to
publishers, I suggest that sometimes it will be a convenience that
more than one publisher will simultaneously want to use. Therefore,
more than one should be allowed.

| 4.12  "atom:modified" Element
| 
|    The "atom:modified" element is a Date construct that indicates the
|    time when the state of the feed was last modified, including any
|    changes to entries therein.  atom:feed elements MUST contain exactly
|    one atom:modified element.
| 
|    The content of an atom:modified element SHOULD have a time zone whose
|    value MUST be "UTC".

Are "SHOULD" and "MUST" reversed in that sentence?

| 4.13  "atom:entry" Element
[...]
|    The atom:entry element MAY contain any namespace-qualified
|    [W3C.REC-xml-names-19990114] elements as children.  Ordering of the
|    element children of atom:entry element MUST NOT be considered
|    significant.

May it contain (non-whitespace) character information item children? I
assume not, but it doesn't say.

| 4.13.7  "atom:issued" Element
| 
|    The "atom:issued" element is a Date construct that indicates the time
|    that the entry was issued.  atom:entry elements MUST contain an
|    atom:issued element, but MUST NOT contain more than one.
| 
|    The content of an atom:issued element MAY omit a time zone.

Why is issued special? If everyone else has to have a time zone, why
not require it here too for consistency?

| 4.13.9  "atom:summary" Element
| 
|    The "atom:summary" element is a Content construct that conveys a
|    short summary, abstract or excerpt of the entry.  atom:entry elements
|    MAY contain an atom:created element, but MUST NOT contain more than
                         ^summary (not created)

| 4.13.10  "atom:content" Element
| 
|    The "atom:content" element is a Content construct that conveys the
|    content of the entry.  atom:entry elements MAY contain one or more
|    atom:content elements.
| 
|    If @type="multipart/alternative", @mode MUST NOT be specified, and
|    content element MUST contain 1 or more content elements.  These

This discussion of multipart/alternative needs expansion. I'm pretty
sure I don't understand what's intended based on just this text.

A couple of general comments:

1. A schema, RELAX NG would be my preference, even if it's
non-normative would be very helpful. I'll volunteer to write and
maintain it, if that helps.

2. No where does the document talk about significant whitespace. I'm
guessing that some folks are expecting that leading and trailing
whitespace isn't significant in some elements, but it doesn't say so.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | A polar bear is just another way of
http://nwalsh.com/            | expressing a rectangular bear.

---

From: Jens Alfke <[email-masked]>
Date: Fri, 9 Jul 2004 14:56:32 -0700

> I'd be happier if the title was a string.

That's so the feed's title can contain markup, without the annoying 
ambiguities present in RSS. I agree that it seems less likely that a 
feed title will require markup than an entry title; but it's still a 
reasonable thing to allow.

(One possible example: some blogs give every post its own feed of 
comments. In this case the title of the comment feed would naturally be 
based on the title of the original post, which can contain markup, most 
likely italics.)

> | 4.11  "atom:info" Element
...
> more than one should be allowed.

But a feed can have only one publisher, so I don't see how "more than 
one publisher" applies here.

_______________________________________
Jens Alfke — Atom/RSS Wrangler — Apple Computer
“Understand that you are another world in miniature,
and that in you are the sun, the moon & also stars”

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 21:57:48 -0400

> for them. Why can't we just say PIs are allowed but provide no

+1.  My Atom feed has PIs for browser-based XSLT transforms. 
Blogger's feeds have PIs for some minimal CSS styling.  There may be
other uses in the future.

-- 
Cheers,
-Mark

---

From: Martin Duerst <[email-masked]>
Date: Sat, 10 Jul 2004 10:50:20 +0900

>I'd be happier if the title was a string.

Given that people might want to put mathematical formulas into titles,
that they may want to put ruby in a title, that they may want to put
multilingual strings in a title and want to clearly indicate that,
and so on, I'd be much happier if title stayed a content construct.

Regards,    Martin.

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 21:55:51 -0400

> that without justification.

This has been discussed at length.  Everyone seems to want Atom to be
described in terms of the InfoSet.  There is a small camp that wants
Atom to be serializable in any InfoSet-compatible form, and a
relatively larger camp that wants Atom to only ever be serializable as
text-based XML 1.0.  See
http://www.imc.org/atom-syntax/mail-archive/msg06161.html and
following thread for a recent flare-up of this discussion.

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 21:59:56 -0400

> containing DocBook V4.3 content (which has no namespace), I'm allowed

Not currently.

How is DocBook usually embedded in other formats if it doesn't have a namespace?

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 22:06:36 -0400

> words to that effect. "Ancestor" can be construed to not include the

The wording here is poor.  I think the intent is simply to follow
section 2.12 of the XML specification [1], which defines the
inheritance model for xml:lang.

Note that the XML specification also makes a passing reference to HTTP
as a transport that may also carry language identification.  I was
researching this earlier this afternoon.  HTTP has a Content-Language
header [2], but it's unclear whether this should be used as the
default language (in the absence of any xml:lang attributes).

Also note that the XML specification does specifically state that
xml:lang (if present) overrides the external language identification. 
This is notable in that it is different in some cases from the
precedence rules for character encoding (RFC 3023), of which we are
all now painfully aware.

To sum up, I think the wording here needs to be clarified and also
possibly include a normative reference to section 14.12 of RFC 2616. 
Can someone wise and knowledgeable in the art of HTTP header
maintenance instruct us on the appropriate semantics of the
Content-Language header?

[1] http://www.w3.org/TR/REC-xml/#sec-lang-tag
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.12

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 22:12:24 -0400

> tedious to go read another spec just for a flat list.

This has been discussed at length, but useful discussion of possible
rel values has been derailed by several proposals that would do away
with this link @rel syntax altogether, in favor of something else
(separate elements, namespaces, etc.).

For background, see http://intertwingly.net/wiki/pie/PaceLinkPurpose
and the list of "related and conflicting proposals."

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 22:19:28 -0400

> not require it here too for consistency?

The original thinking behind issued's lack of timezone is here:
http://intertwingly.net/blog/2003/07/01/Subjective-and-objective-dates

Note that recently, "issued" seems to have drifted into other
meanings.  It is a point of active discussion, and the original use
case seems to be getting lost in the shuffle.  See for example this
recent flare-up of this discussion:
http://www.imc.org/atom-syntax/mail-archive/msg06186.html

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 22:21:22 -0400

> maintain it, if that helps.

http://www.dpawson.co.uk/relaxng/atom03/

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 9 Jul 2004 22:16:10 -0400

> I'd be happier if the title was a string.

Very early snapshots of Atom had title has a string, but Blogger
allows markup in post titles, and they are adamant about preserving
this.  It seemed easier to make it a Content construct than something
halfway.

Note that the default content type for all Content constructs,
including title, is plain text.  If the title contains escaped markup,
it must be specified as type="text/html".  (Or, since I know you hate
the idea of escaped markup, type="application/xhtml+xml" plus inline
XHTML markup in the appropriate namespace.)

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Fri, 09 Jul 2004 19:30:21 -0700

>> |    All elements and attributes in an Atom document MUST be

Norm's right to call this out, it's silly as stated.  First of all, 
*not* all attributes are namespace-qualified, consider <atom:link 
href=""> or <atom:content type="">, neither href= nor type= are in a 
namespace nor need they be.

Also, it seems completely unreasonable to rule out the use of legacy 
XML vocabularies that have no namespace in <atom:content>.  Like, for 
example, RSS2. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Fri, 09 Jul 2004 23:06:33 -0400

Tim Bray wrote:

> Also, it seems completely unreasonable to rule out the use of legacy XML 
> vocabularies that have no namespace in <atom:content>.  Like, for 
> example, RSS2. -Tim

In general, I have found it easier to talk in terms of such vocabularies 
being in a namespace consisting of an empty string.  IMHO, the following 
should be legal:

<feed xmlns="http://purl.org/atom/ns#">
   <content>
     <book xmlns="">
       <chapter>
       </chapter>
     </book>
   </content>
</feed>

Annoyingly, <db:book xmlns:db=""> is not allowed in XML.  This namespace 
declaration is outright illegal in XML 1.0, and has the effect of 
undeclaring the db prefix in XML 1.1.

- Sam Ruby

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2004 21:54:33 -0700

+1

This was noticed early on, but there's never been a discussion of what 
the proper thing to say is.

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2004 22:02:30 -0700

Unless there's an objection, I'll consider the issues marked 
'Editorial' below as such, and will incorporate proposals for them into 
the next I-D.

> Am I to assume document information item here?

Editorial.

> words to that effect. "Ancestor" can be construed to not include the

Editorial.

>                                                                      ^ 
> when?

Editorial.

> tedious to go read another spec just for a flat list.

This has not been done because that list is not stable, and may 
ultimately end up in an IANA registry.

> "MUST be a string"? How can an attribute *not* be a string. Does this

Editorial.

> Are "SHOULD" and "MUST" reversed in that sentence?

This isn't a mistake; i.e., AFAIK it reflects current consensus 
(although personally I don't agree with this approach).

> |    MAY contain an atom:created element, but MUST NOT contain more 

Editorial.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2004 22:05:20 -0700

The only use case for atom:info that I'm aware of does not require 
standardisation; it could be achieved just as effectively with a 
site-specific extension. Therefore, I propose we drop this element.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 10 Jul 2004 15:05:07 +1000

> |    The content of an atom:modified element SHOULD have a time zone whose

is this a valid W3C Date-Time string?

    2003-12-13T18:30:02UTC

no.

there are actually three ways of writing a W3C Date-Time string whose time
zone is UTC, and that is with the time zone part being "+00:00" or "-00:00"
or "Z". Sticking UTC in there is invalid (and feedvalidator.org concurs).

The "Z" signifies UTC, and is equivalent to "+00:00". The "+00:00" is a
valid timezone offset string, which coincidentally is also of the same value
as UTC. The "-00:00" is just me being pedantic. :-P

By the way, the "Z" MUST be capital "Z".

http://www.w3.org/TR/NOTE-datetime

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 10 Jul 2004 14:35:12 +1000

> "MUST be a string"? How can an attribute *not* be a string. Does this

maybe the intent is to avoid people using title="&lt;b&gt;B&lt;/b&gt;old is
old" and hoping they'll get *B*old is old.

if so, +1

e.

*B* is of course the letter B in BOLD.

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 07:26:01 -0400

/ Mark Pilgrim <[email-masked]> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <[email-masked]> wrote:
|> |    All elements and attributes in an Atom document MUST be
|> |    namespace-qualified.
|> 
|> Does this apply only to top-level elements in an atom:feed or
|> atom:entry element? If I want to ship around a content constructor
|> containing DocBook V4.3 content (which has no namespace), I'm allowed
|> to, aren't I?
|
| Not currently.
|
| How is DocBook usually embedded in other formats if it doesn't have a namespace?

By putting it in a container that tells the application it's DocBook.
Perhaps:

  <atom:content type="application/docbook+xml" xmlns="">
    <para>Like this, for example.</para>
  </atom:content>

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Perhaps the most valuable result of all
http://nwalsh.com/            | education is the ability to make
                              | yourself do the thing you have to do,
                              | when it ought to be done, whether you
                              | like it or not.--Thomas H. Huxley

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 07:29:08 -0400

/ Mark Pilgrim <[email-masked]> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <[email-masked]> wrote:
|> |    The "rel" attribute indicates the type of relationship that the link
|> |    represents.  Link constructs MUST have a rel attribute, whose value
|> |    MUST be a string, and MUST be one of the values enumerated in the
|> |    Atom Protocol specification [Atom-protocol].
|> 
|> Please duplicate that list here. I don't care about the protocol and it's
|> tedious to go read another spec just for a flat list.
|
| This has been discussed at length, but useful discussion of possible
| rel values has been derailed by several proposals that would do away
| with this link @rel syntax altogether, in favor of something else
| (separate elements, namespaces, etc.).
|
| For background, see http://intertwingly.net/wiki/pie/PaceLinkPurpose
| and the list of "related and conflicting proposals."

Fair enough, I'm not sure I like the link/@rel syntax very much
myself, but my point was simply that if the link/@rel syntax survives,
the list of legal @rel values should be enumerated explicitly in the
format spec instead of sending the poor reader off to another document
just for this one list.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The bane of my existence is doing
http://nwalsh.com/            | things that I know the computer could
                              | do for me.--Dan Connolly

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:05:16 -0400

/ Jens Alfke <[email-masked]> was heard to say:
| On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:
|
|> It seems slightly odd to me that the title is a Content construct. I
|> think
|> I'd be happier if the title was a string.
|
| That's so the feed's title can contain markup, without the annoying
| ambiguities present in RSS. I agree that it seems less likely that a
| feed title will require markup than an entry title; but it's still a
| reasonable thing to allow.

I suppose. It's going to make displaying the title harder though, if
your processor doesn't know the markup vocabulary. Insisting that
titles be strings wouldn't seem an undue hardship to me.

| (One possible example: some blogs give every post its own feed of
| comments. In this case the title of the comment feed would naturally
| be based on the title of the original post, which can contain markup,
| most likely italics.)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Anyone who can handle a needle
http://nwalsh.com/            | convincingly can make us see a thread
                              | which is not there.--E. H. Gombrich

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:06:15 -0400

/ Jens Alfke <[email-masked]> was heard to say:
|> | 4.11  "atom:info" Element
| ...
|> If it's not meaningful to processors and may be a convenience to
|> publishers, I suggest that sometimes it will be a convenience that
|> more than one publisher will simultaneously want to use. Therefore,
|> more than one should be allowed.
|
| But a feed can have only one publisher, so I don't see how "more than
| one publisher" applies here.

Uhm. I guess I was thinking that I might publish a feed which might be
republished by someone else. But maybe in that case, they're
republishing the entries from my feed, not my feed itself.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | It's a poor sort of memory that only
http://nwalsh.com/            | works backward.--Lewis Carroll

---

From: Sam Ruby <[email-masked]>
Date: Sat, 10 Jul 2004 08:10:32 -0400

> (although personally I don't agree with this approach).

I'm not sure I can assess what the current consensus is, I can comment 
on the original intent based on what the FeedValidator currently implements:

W3DTFDateNoTimezone is a Warning (will display, but will not cause a 
feed to be marked as invalid)

W3DTFDateNonUTC is Informational (and therefore by default does not display)

I would be comfortable with reversing the "SHOULD" and "MUST" in that 
sentence.

- Sam Ruby

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:08:14 -0400

/ Mark Pilgrim <[email-masked]> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <[email-masked]> wrote:
|> |    Atom documents are specified in terms of the XML Information Set,
|> |    serialised as XML 1.0 and identified with the "application/atom+xml"
|> |    media type.
|> 
|> I find the mention of the serialization format here a bit odd. If the
|> spec is going to describe things in terms of the infoset, then the
|> serialization form is irrelevant. If the spec wants to mandate a
|> serialization form, that's fine too, but I don't think it should do
|> that without justification.
|
| This has been discussed at length.  Everyone seems to want Atom to be
| described in terms of the InfoSet.  There is a small camp that wants
| Atom to be serializable in any InfoSet-compatible form, and a
| relatively larger camp that wants Atom to only ever be serializable as
| text-based XML 1.0.  See
| http://www.imc.org/atom-syntax/mail-archive/msg06161.html and
| following thread for a recent flare-up of this discussion.

I understand that. I favor 1.0 or its successors myself. In
particular, I think taking the position that Ethopic blogs can't use
Atom is short-sighted.

But the point of my comment was that the spec should have a section
about the serialized form, it shouldn't mention it only in passing.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | History teaches us that men and nations
http://nwalsh.com/            | behave wisely once they have exhausted
                              | all other alternatives.--Abba Eban

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:11:33 -0400

If the editor is content that they're editorial, I'm happy :-)

I think the MUST/MAY might not be, but I'll call that out in a message
with a separate subject.

/ Mark Nottingham <[email-masked]> was heard to say:
| Unless there's an objection, I'll consider the issues marked
| 'Editorial' below as such, and will incorporate proposals for them
| into the next I-D.
|
| On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:
|> [...]
|> |    Therefore, when this specification uses the term "element," it is
|> |    refering to an Element Information Item in Infoset terms.
|> Likewise,
|> |    when it uses the term "attribute," it is refering to an Attribute
|> |    Information Item.
|>
|> What about entity, document, etc.? Are those words shorthand as well?
|>
|> | 2.  Atom Documents
|> |
|> |    An Atom document
|>
|> Am I to assume document information item here?
|
| Editorial.
|
|> |    [RFC3066].  When determining element content's natural
|> language, the
|> |    first xml:lang attribute encountered in that element's
|> ancestors MUST
|> |    be used.
|>
|> "...encountered on that element or the first of its ancestors..." or
|> words to that effect. "Ancestor" can be construed to not include the
|> current element.
|
| Editorial.
|
|> |    the author.  It MAY be the name of a corporation or other
|> entity no
|>
|> ^ when?
|> |    individual authors can be named.  Person constructs MUST contain
|
| Editorial.
|
|> |    The "rel" attribute indicates the type of relationship that the
|> link
|> |    represents.  Link constructs MUST have a rel attribute, whose
|> value
|> |    MUST be a string, and MUST be one of the values enumerated in the
|> |    Atom Protocol specification [Atom-protocol].
|>
|> Please duplicate that list here. I don't care about the protocol and
|> it's
|> tedious to go read another spec just for a flat list.
|
| This has not been done because that list is not stable, and may
| ultimately end up in an IANA registry.
|
|> |    link.  Link constructs MAY have a title attribute, whose value
|> MUST
|> |    be a string.
|>
|> "MUST be a string"? How can an attribute *not* be a string. Does this
|> add anything?
|
| Editorial.
|
|> | 4.12  "atom:modified" Element
|> |
|> |    The "atom:modified" element is a Date construct that indicates the
|> |    time when the state of the feed was last modified, including any
|> |    changes to entries therein.  atom:feed elements MUST contain
|> exactly
|> |    one atom:modified element.
|> |
|> |    The content of an atom:modified element SHOULD have a time zone
|> whose
|> |    value MUST be "UTC".
|>
|> Are "SHOULD" and "MUST" reversed in that sentence?
|
| This isn't a mistake; i.e., AFAIK it reflects current consensus
| (although personally I don't agree with this approach).
|
|> | 4.13.9  "atom:summary" Element
|> |
|> |    The "atom:summary" element is a Content construct that conveys a
|> |    short summary, abstract or excerpt of the entry.  atom:entry
|> elements
|> |    MAY contain an atom:created element, but MUST NOT contain more
|> than
|>                          ^summary (not created)
|
| Editorial.
|
| --
| Mark Nottingham     http://www.mnot.net/

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Furious activity is no substitute for
http://nwalsh.com/            | understanding.--H. H. Williams

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:09:42 -0400

/ Mark Pilgrim <[email-masked]> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <[email-masked]> wrote:
|> 1. A schema, RELAX NG would be my preference, even if it's
|> non-normative would be very helpful. I'll volunteer to write and
|> maintain it, if that helps.
|
| http://www.dpawson.co.uk/relaxng/atom03/

Right. I have one too, but I hadn't gone back to compare the 00 draft
with the 0.3 draft.

And my point is that I want it in the spec, as a normative or
non-normative appendix, for example.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | A facility for quotation covers the
http://nwalsh.com/            | absence of original thought.--Lord
                              | Peter Wimsey

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:16:11 -0400

atom:modified for atom:feed says:

   The content of an atom:modified element SHOULD have a time zone whose
   value MUST be "UTC".

atom:modified for atom:entry says:

   The content of an atom:modified element MUST have a time zone whose
   value SHOULD be "UTC".

If that's not a mistake, I can't fathom the rationale. If the
semantics of atom:modified on a feed are really that different from
atom:modified on an entry, I think maybe they need different element
names.

And if all we can say about an element is that it SHOULD have a time zone,
then I think we better say how an element without a time zone is to be
interpreted.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | I don't know the key to success, but
http://nwalsh.com/            | the key to failure is trying to please
                              | everybody.--Bill Cosby

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:18:44 -0400

/ Mark Nottingham <[email-masked]> was heard to say:
| The only use case for atom:info that I'm aware of does not require
| standardisation; it could be achieved just as effectively with a
| site-specific extension. Therefore, I propose we drop this element.

Sounds like a good design rationale to me: +1

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | In real life, unlike in Shakespeare,
http://nwalsh.com/            | the sweetness of the rose depends upon
                              | the name it bears. Things are not only
                              | what they are. They are, in very
                              | important respects, what they seem to
                              | be.--Hubert H. Humphrey

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:19:52 -0400

/ Eric Scheid <[email-masked]> was heard to say:
| On 10/7/04 7:19 AM, "Norman Walsh" <[email-masked]> wrote:
|
|> |    link.  Link constructs MAY have a title attribute, whose value MUST
|> |    be a string.
|> 
|> "MUST be a string"? How can an attribute *not* be a string. Does this
|> add anything?
|
| maybe the intent is to avoid people using title="&lt;b&gt;B&lt;/b&gt;old is
| old" and hoping they'll get *B*old is old.
|
| if so, +1

It's not a Content construct, so I wouldn't expect that to work. But
if that's the intent, then I think it just needs a little editorial
clarification.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | An author is a fool who, not content
http://nwalsh.com/            | with boring those he lives with,
                              | insists on boring future
                              | generations.--Charles de Montesquieu

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 10 Jul 2004 08:40:10 -0400

> non-normative appendix, for example.

Great.  Work with Dave Pawson to update it, and write up a Pace when
you're done.

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Sat, 10 Jul 2004 08:42:17 -0400

> then I think we better say how an element without a time zone is to be

Perhaps something like this?

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#date

- Sam Ruby

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:49:09 -0400

/ Martin Duerst <[email-masked]> was heard to say:
| At 17:19 04/07/09 -0400, Norman Walsh wrote:
|
|>| 4.3  "atom:title" Element
|>|
|>|    The "atom:title" element is a Content construct that conveys a
|>
|>It seems slightly odd to me that the title is a Content construct. I think
|>I'd be happier if the title was a string.
|
| Given that people might want to put mathematical formulas into titles,
| that they may want to put ruby in a title, that they may want to put
| multilingual strings in a title and want to clearly indicate that,
| and so on, I'd be much happier if title stayed a content construct.

Fair enough. I withdraw my comment.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | If someone tells you he is going to
http://nwalsh.com/            | make 'a realistic decision', you
                              | immediately understand that he has
                              | resolved to do something bad.--Mary
                              | McCarthy

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 10 Jul 2004 09:33:30 -0700 (PDT)

> particular, I think taking the position that Ethopic

How does Atom prevent Ethopic blogs from being
syndicated? XML 1.0 can have Ethopic content just
fine, just not Ethopic element and attribute names.
Given that an Ethopic blogger will have to use suck it
up and deal with English element names for the Atom
namespaced elements and attributes as well as the HTML
they are using to publish on the Web I'm not sure why
they are any more disenfranchised by Atom. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 10:05:56 -0700

This was beat to death a long, long time ago, but I can't find the 
references. I'm also dissatisfied with the current language; IMHO we 
should just use W3CDateTime and be done with it.

---

From: Ken MacLeod <[email-masked]>
Date: 10 Jul 2004 12:09:56 -0500

Norman Walsh <[email-masked]> writes:

> By putting it in a container that tells the application it's
> DocBook.  Perhaps:
> 

Media types are applied to entity bodies as defined by their
respective specifications.  RFC3023, which DocBook makes reference to
in the encoding considerations of its [proposed?] media type
registration, refers to these as "document entities".

Do you consider the XML text within the atom:content element to be a
"document entity" in the same sense as the entity body of, say, HTTP
or MIME?  If not, what would be a "general profile" for XML fragments
that may appear inline of other document entities?

PaceSimpleContentType attempts to address this problem by removing the
media type indicator for inline XML content and requiring a registered
profile for fragments.  It contains a "general profile" for XML
fragments, but makes its determination based on the XML namespace of
the root element.  Obviously that wouldn't work in this case.
Suggestions?

  -- Ken

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 18:14:32 -0400

/ Dare Obasanjo <[email-masked]> was heard to say:
| How does Atom prevent Ethopic blogs from being
| syndicated? XML 1.0 can have Ethopic content just
| fine, just not Ethopic element and attribute names.
| Given that an Ethopic blogger will have to use suck it
| up and deal with English element names for the Atom
| namespaced elements and attributes as well as the HTML
| they are using to publish on the Web I'm not sure why
| they are any more disenfranchised by Atom. 

You are absolutely correct. I still think it would be reasonable to
allow XML 1.0 and its successors, but my argument about Ethiopic
dramatically overstated the case. Requiring XML 1.0 serialization
would only forbid the creation of extensions to Atom that used
Ethiopic element or attribute names, not the syndication of Ethiopic
content.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | "Abstraction, abstraction and
http://nwalsh.com/            | abstraction." This is the answer to the
                              | question, "What are the three most
                              | important words in programming?"--Paul
                              | Hudak

---

From: Martin Duerst <[email-masked]>
Date: Sun, 11 Jul 2004 09:27:32 +0900

Is the lack of a namespace for DocBook V4.3 considered a feature
(and in that case, why), an oversight, a timing issue, or what?
My assumption was that these days, any halfway serious markup
vocabulary should have a namespace, but maybe I'm wrong.

Regards,    Martin.

---

From: Norman Walsh <[email-masked]>
Date: Sun, 11 Jul 2004 09:02:17 -0400

/ Martin Duerst <[email-masked]> was heard to say:
| Is the lack of a namespace for DocBook V4.3 considered a feature
| (and in that case, why), an oversight, a timing issue, or what?
| My assumption was that these days, any halfway serious markup
| vocabulary should have a namespace, but maybe I'm wrong.

DocBook predates namespaces by, uhm, almost a decade. Also, we still
publish an SGML version, where namespaces don't exist at all.

DocBook V5.0 will be in a namespace, but there are tens of thousands,
probably hundreds of thousands, of DocBook documents out there in no
namespace and that's not going to change very quickly.

Anyway, I think treating documents that happen to be in a vocabulary
with no namespace like second class citizens is unnecessary in this
case.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Wisdom is only a comparative quality,
http://nwalsh.com/            | it will not bear a single
                              | definition.--Marquess of Halifax