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

From: Anne van Kesteren <[email-masked]>
Date: Mon, 19 Jul 2004 21:25:14 +0200

[email-masked] wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt

Hmm... 404 anyone?

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: [email-masked]
Date: Mon, 19 Jul 2004 15:19:47 -0400

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-01.txt
	Pages		: 27
	Date		: 2004-7-19
	
This specification describes Atom, an XML-based Web content and
   metadata syndication format.

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-01.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-01.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: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 19 Jul 2004 15:26:54 -0400

Sometimes the announcements get out before the archive web site is updated.
The doc should be there "soon" (in a matter of hours).

-Scott-

> -----Original Message-----
> From: Anne van Kesteren [mailto:[email-masked]] 
> Sent: Monday, July 19, 2004 3:25 PM
> To: Atom Syntax
> Subject: Re: I-D ACTION:draft-ietf-atompub-format-01.txt
> 
> 
>

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 17:43:51 -0400

|    Any element in an Atom Document MAY have an xml:lang attribute, whose
|    content indicates the default natural language of the element's
|    content.  Requirements regarding the content and interpretation of
|    xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section
|    2.12.  For convenience, the most important are summarised here:
| 
|       The content of this attribute must be a language tag [RFC3066] or
|       an empty string (e.g., xml:lang=""), which indicates that there is
|       no language information available.
|       If an element does not have an xml:lang element, the first
|       xml:lang attribute in its ancestors indicates the natural language
|       of its content.
| 
|    [[ feedback as to whether this listing is helpful or not would be
|    appreciated; re-stating the requirements of other specifications is
|    tricky.  ]]

Drop it. If it isn't dropped, I suggest making the two points into
a bulleted list:

     * The content of this attribute must be a language tag [RFC3066] or
       an empty string (e.g., xml:lang=""), which indicates that there is
       no language information available.
     * If an element does not have an xml:lang element, the first
       xml:lang attribute in its ancestors indicates the natural language
       of its content.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | [The internet is] the largest
http://nwalsh.com/            | equivalence class in the reflexive
                              | transitive symmetric closure of the
                              | relationship 'can be reached by an IP
                              | packet from.'--Seth Breidbart

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 17:49:39 -0400

The -01 draft describes two elements as having "unstructured text" as
their content:

[...]
| 3.2.1  "atom:name" Element
| 
|    The "atom:name" element's content conveys a human-readable name for
|    the person.  Person constructs MUST contain exactly one "atom:name"
|    element, whose content is unstructured text.
[...]
| 3.4.5  "title" Attribute
| 
|    The "title" attribute conveys human-readable information about the
|    link.  Link constructs MAY have a title attribute, whose value is
|    unstructured text.

It also describes the 'version' attribute this way. What is the intent here?
Does "unstructured text" mean a string without markup? Or does it mean that
the structure is ignored? Is this allowed:

  <atom:title>I <html:em>Really</html:em> Mean It</atom:title>

I think the answer is "no". If that's the case, I suggest that the
descriptions be extended to explicitly forbid markup.

   Person constructs MUST contain exactly one "atom:name"
   element, whose content is unstructured text. The "atom:name" element
   must not contain any embedded element markup.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Taste ripens at the expense of
http://nwalsh.com/            | happiness.--Jules Renard

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 17:52:22 -0400

| 4.  The "atom:feed" Element
| 
|    The "atom:feed" element is the document (i.e., top-level) element of
|    an Atom Feed Document, acting as a container for metadata and data
|    associated with the feed.  Its first element child MUST be atom:head,
|    which MAY be followed zero or more atom:entry child elements.

I don't think this description goes far enough to forbid text content in
atom:feed, which I think should be forbidden. Do we agree it should
be forbidden?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | My fate cannot be mastered; it can only
http://nwalsh.com/            | be collaborated with and thereby, to
                              | some extent, directed. Nor am I the
                              | captain of my soul; I am only its
                              | noisiest passenger.--Aldous Huxley

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 17:55:56 -0400

| 5.8  "atom:created" Element
| 
|    The "atom:created" element is a Date construct that indicates the
|    time that the entry was created.  atom:entry elements MAY contain an
|    atom:created element, but MUST NOT contain more than one.
| 
|    The content of an atom:created element MUST have a time zone whose
|    value SHOULD be "UTC".
| 
|    If atom:created is not present, its content MUST considered to be the
|    same as that of atom:modified.

I would have expected it to be the same as atom:issued. I'm not sure
either is really the obviously correct answer. Is there value in
providing a default if it isn't specified?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Extinction is an endless crime, quietly
http://nwalsh.com/            | slaughtering all the lives that would
                              | have been.--Captian Sverre (James
                              | Morrow)

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 17:58:18 -0400

| 5.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
|    content elements MUST NOT specify @type="multipart/alternative" (i.e.
|    only one level of nesting is allowed).  Consumers SHOULD look at all
|    alternative content elements and determine which one is most
|    suitable, based on which @type and @mode the consumer supports, and
|    preferences specified by the end user (if any).  Consumers SHOULD NOT
|    render more than one content alternative.

I tried a little harder to understand this text this time. I think the
intent is:

  <atom:content type="multipart/alternative">
    <atom:content type="text/html">...</atom:content>
    <atom:content type="application/pdf">...</atom:content>
    ...
  </atom:content>

If that's the case, I think the phrase "MUST contain 1 or more content
elements". Perhaps it would be clearer to say "MUST contain 1 or more
atom:content elements"? Or maybe I just don't understand yet.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | And gentlemen in England now a-bed /
http://nwalsh.com/            | Shall think themselves accursed they
                              | were not here, / And hold their
                              | manhoods cheap whiles any speaks / That
                              | fought with us upon Saint Crispin's
                              | day.--William Shakespeare, Henry V

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 17:58:59 -0400

| 5.12  "atom:origin" Element
| 
|    The "atom:origin" element's content conveys the original source of
|    the entry; e.g., the feed where the entry was first published.
| 
|    If the source is an Atom Feed Document, then the content of
|    atom:origin MUST be the same, character-for-character, as that of the
|    href attribute of the atom:link element that has a rel attribute
|    value of "alternate" in that document's atom:head section (i.e., the
|    XPath expression "/atom:feed/atom:head/atom:link[@rel='alternate']/
|    @href").

Really? Not the atom:id of the feed? That seems...odd.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The sudden disappointment of hope
http://nwalsh.com/            | leaves a scar which the ultimate
                              | fulfillment of that hope never entirely
                              | removes.--Thomas Hardy

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 19 Jul 2004 23:18:05 +0100

> atom:feed, which I think should be forbidden. Do we agree it should

+1 to forbidden and to stating so.

cheers
Bill

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 19 Jul 2004 18:19:46 -0400

> atom:feed, which I think should be forbidden. Do we agree it should

+1

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 19 Jul 2004 23:28:40 +0100

> Really? Not the atom:id of the feed? That seems...odd.

Not that odd, since atom:id is optional. I would have used atom:id 
were that not the case.

cheers
Bill

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 19 Jul 2004 15:30:37 -0700

>It also describes the 'version' attribute this way. What is the intent here?

The intent in the version attribute is that you should not imply any 
structure to the text in the attribute. That is, you should not imply 
that "2.1" comes after "2", or that the version after "2" will be "3".

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 19 Jul 2004 23:25:15 +0100

Norman Walsh wrote:

> Does "unstructured text" mean a string without markup? 

I assume it means #PCDATA.

>    must not contain any embedded element markup.

    Person constructs MUST contain exactly one
    "atom:name" element, whose content must not
    contain any embedded element markup.

Once you say no tags the "unstructured text" bit is redundant.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 19 Jul 2004 18:41:20 -0400

Norman Walsh wrote:
> text content in atom:feed, which I think should be forbidden. 
> Do we agree it should be forbidden?

	It should be forbidden. I agree.

		bob wyman

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 19 Jul 2004 23:54:42 +0100

Bill de hÓra wrote:

> "atom:feed elements MUST have a "version" attribute whose content 
> indicates the version of the Atom specification that the feed conforms 
> to.  The content of this attribute element should be treated as opaque, 
> unstructured text."

s/element//

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 19 Jul 2004 23:52:52 +0100

> that "2.1" comes after "2", or that the version after "2" will be "3".

If that's the intent, how about adding "opaque" and a constraint:

"atom:feed elements MUST have a "version" attribute whose content 
indicates the version of the Atom specification that the feed 
conforms to.  The content of this attribute element should be 
treated as opaque, unstructured text."

?

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Mon, 19 Jul 2004 15:54:16 -0700

> that "2.1" comes after "2", or that the version after "2" will be "3".

Which, by the way, I probably disagree with; I believe 
extensibility/versioning proposals such as Dave Orchard's recent 
submission are going to work better if there is a clear ordering on 
version stamps. -Tim

---

From: Norman Walsh <[email-masked]>
Date: Mon, 19 Jul 2004 19:24:15 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Paul Hoffman / IMC wrote:
|
|> The intent in the version attribute is that you should not imply any
|> structure to the text in the attribute. That is, you should not
|> imply that "2.1" comes after "2", or that the version after "2" will
|> be "3".
|
| If that's the intent, how about adding "opaque" and a constraint:
|
| "atom:feed elements MUST have a "version" attribute whose content
| indicates the version of the Atom specification that the feed conforms
| to.  The content of this attribute element should be treated as
| opaque, unstructured text."

How about removing "unstructured text" in that sentence. Using the same
phrase for two different purposes is confusing.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | People say law but they mean wealth.--
http://nwalsh.com/            | Emerson

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 00:33:30 +0100

Bill de hÓra wrote:

> Like this:
> to.  The content of this attribute element should be considered opaque." *

(aaarrgh) s/element//:

"atom:feed elements MUST have a "version" attribute whose content 
indicates the version of the Atom specification that the feed 
conforms to.  The content of this attribute should be considered 
opaque."

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 00:31:43 +0100

Like this:

considered opaque." *

?

cheers
Bill

* "considered opaque" sounded 'better' than "treated opaquely"

---

From: Sam Ruby <[email-masked]>
Date: Mon, 19 Jul 2004 19:50:46 -0400

Bill de hÓra wrote:
>> | |    The "atom:origin" element's content conveys the original source of
>> | |    If the source is an Atom Feed Document, then the content of
> Not that odd, since atom:id is optional. I would have used atom:id were 
> that not the case.

Section 5.5  "atom:id" Element :

    atom:entry MUST contain exactly one atom:id element.  The content of
    this element MUST be a URI.

- Sam Ruby

P.S.  Yes, this is a change from format-00

---

From: Eric Scheid <[email-masked]>
Date: Tue, 20 Jul 2004 11:19:30 +1000

> Once you say no tags the "unstructured text" bit is redundant.

Not entirely. Some places might want to emit names like this:

    <name>de hÓra, Bill</name>

that is structured, but it has no embedded markup.

Similarly,<feed @version="1.2.3" /> is structured, as is

    <generator>
        <version>MozAtom/5.0 (Macintosh; U; PPC Mac OS X; en)
AppleWebKit/125.2 (KHTML, like Gecko) FooBar/125.8</version>
    </generator>

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 20 Jul 2004 12:12:53 +1000

> Really? Not the atom:id of the feed? That seems...odd.

additionally, 

(1) there may actually be multiple elements that match that XPath, they just
might have different @type values...

    <feed>
        <head>
            <link rel="alternate" type="text/html" href="..." />
            <link rel="alternate" type="application/atom+xml" href="..." />
            ...

(2) another problem which might arise is xml:base implications...

  <feed xml:base="http://example.org/myblog/">
    <link rel="alternate" type="application/atom+xml"
        href="latest.atom" />

character for character, atom:origin would be thus be "latest.atom". Not
very useful.

e.

---

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 21:55:21 -0500

Sam Ruby <[email-masked]> writes:

>     atom:entry MUST contain exactly one atom:id element.  The
>     content of this element MUST be a URI.

I think Bill's referring to 4.2.6, atom:feed/atom:id, which is still
optional.

  -k

---

From: Mark Pilgrim <[email-masked]>
Date: Mon, 19 Jul 2004 23:13:34 -0400

> might have different @type values...

Or different @hreflang values.

-- 
Cheers,
-Mark

---

From: Eric Scheid <[email-masked]>
Date: Tue, 20 Jul 2004 13:11:05 +1000

>   this element MUST be a URI.

clarification please...

    is atom:origin meant to reference the origin <feed>,
    or the origin <entry>?

Section 5.12 (atom:entry/atom:origin) says <feed>, which doesn't sound as
useful as <entry>, and I also note that "/atom:feed/atom:head/atom:id" is
actually optional (section 4.2.6 atom:head/atom:id).

e.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 13:51:22 +0100

> P.S.  Yes, this is a change from format-00

(mumble... on vacation.. excuses... mumble...)

I would be happy for this element to point at atom:id then.

OT: did I miss discussion for that change here?

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 14:03:10 +0100

> that is structured, but it has no embedded markup.

I'm not sure what you;re after here - are you looking to constrain 
processing on the text of atom:name?

I read unstructured text as not being relevant to Person constructs, 
but relevant to the version attribute - ie for Person "unstructured 
text" is a moniker for #PCDATA.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 20 Jul 2004 06:13:19 -0700 (PDT)

--- Tim Bray <[email-masked]> wrote:
> version stamps. 

Why? What is wrong with 'if this is a namespace I
recognize then I support this format'? This is the
essence of Dave Orchard's model and one I tend to
agree with. 

Overlaying such semantics on version numbers as well
means that clients then slice versioning across
multiple axes, do I support this major or minor
version number or do I support this namespace name.
There should be a clear single point for applications
to determine compatibility. 

=====
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!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 09:36:11 -0400

> OT: did I miss discussion for that change here?

http://www.intertwingly.net/wiki/pie/PaceEntryIdRequired
http://www.imc.org/atom-syntax/mail-archive/msg07152.html
http://www.imc.org/atom-syntax/mail-archive/msg06955.html

- Sam Ruby

---

From: Norman Walsh <[email-masked]>
Date: Tue, 20 Jul 2004 09:37:54 -0400

[...]
| 1.  Introduction
| 
|    Atom is an XML-based document format intended to allow lists of
|    related information, known as "feeds", to be synchronised between
|    publishers and consumers.  Feeds are composed of a number of items,
|    known as "entries", each with an extensible set of attached metadata.
|    For example, each entry has a title.
| 
|    The primary use case that Atom addresses is the syndication of Web
|    content such as Weblogs and news headlines, to Web sites as well as
            ^ add comma or        delete comma ^
[...]
| 1.2  Example
| 
|    A minimal, single-entry Atom Feed Document:
| 
|    <?xml version="1.0" encoding="utf-8"?>
|    <feed version="draft-ietf-atompub-format-01: do not deploy"
|     xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-01">
|      <head>
|        <title>Example Feed</title>
|        <link rel="alternate" type="text/html"
|         href="http://example.org/index.atom"/>

The extension .atom seems odd for a text/html document.

[...]
| 3.1.2  "mode" Attribute
| 
|    Content constructs MAY have a "mode" attribute, whose value indicates
|    the method used to encode the content.  When present, this
|    attribute's value MUST be listed below.  If not present, its value
|    MUST be considered to be "xml".

"If not present,...be 'xml'" seems a little clumsy. Rephrase?

[...]
| 3.2.3  "atom:email" Element
| 
|    The "atom:email" element's content conveys an e-mail address
|    associated with the persons.  Person constructs MAY contain an
|    atom:email element, but MUST NOT contain more than one.  Its content
|    MUST be an e-mail address [RFC2822].
| 
|    Person constructs MAY be extended by namespace-qualified element
|    children.
| 
|    Ordering of the element children of Person constructs MUST NOT be
|    considered significant.

The last two paras should go before 3.2.1, I think.

[...]
| 3.4  Link Constructs
| 
|    A Link construct is an element that MUST NOT have any child content,
|    and has the following attributes:

Woudl it be clearer to express this in the affirmative rather than the
negative: "MUST be empty"?

[...]
| 4.2.2  "atom:link" Element
| 
|    The "atom:link" element is a Link construct that conveys a URI
|    associated with the feed.  The nature of the relationship as well as
|    the link itself is determined by the element's content.

Links are empty so I find "determined by the element's content"
ambiguous. Which element's content? This might be read as meaning the
content returned by dereferencing the link, which I don't think is
intended.

[...]
| 4.2.7  "atom:generator" Element
| 
|    The "atom:generator" element's content indentifies the software agent
|    used to generate the feed, for debugging and other purposes.
|    atom:head elements MAY contain an atom:generator element, but MUST
|    NOT contain more than one.
| 
|    The content of this element, when present, MUST be a string that is a
|    human-readable name for the generating agent.

I think "MUST be a string" is clearer than "unstructured text" (in the
element context, not the attribute context). I suggest using it
throughout.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Growth for the sake of growth is the
http://nwalsh.com/            | ideology of the cancer cell.--Edward
                              | Abbey

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 16:33:08 +0100

> http://www.imc.org/atom-syntax/mail-archive/msg06955.html

Ahh; belated +1 from me then :)

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 16:58:43 +0100

>>> P.S.  Yes, this is a change from format-00

It seems there is some confusion here. The atom:origin element 
points to the feed/head id not the feed/entry id (the refs you 
mentioned were for entry ids). The feed/head id is still optional in 
[01]. If the feed/head is published without an id there is nothing 
for an atom:origin to relate to, hence the original reason to point 
at the link remains. In other words if we were to change origin to 
point at the feed/head id, it wouldn't make sense to have an origin 
element in a feed that doesn't have a feed/head id, when that entry 
is in fact in its origin feed (the non-synthetic case). I think my 
first reply to Norm stands.

[01]

---

From: Walter Underwood <[email-masked]>
Date: Tue, 20 Jul 2004 11:51:19 -0700

> that is structured, but it has no embedded markup.

That is essentially unstructured because it is a mess to interpret.
You have to special case ", Jr." and so on. Context-sensitive parsing.

Real structured names look like this:

<name><given>Bill</given><family>de hÓra</family></name>

That also works for "Murata Makoto".

If we want structured names, we start with the X.500 name system
(above) and also look at AACR2 (library cataloguing rules).
Anything short of that is US-centric hacks.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Graham <[email-masked]>
Date: Tue, 20 Jul 2004 17:25:28 -0400

On 20 Jul 2004, at 11:58 am, Bill de hÓra wrote:

> It seems there is some confusion here. The atom:origin element points 
> to the feed/head id not the feed/entry id (the refs you mentioned were 
> for entry ids). The feed/head id is still optional in [01]. If the 
> feed/head is published without an id there is nothing for an 
> atom:origin to relate to, hence the original reason to point at the 
> link remains. In other words if we were to change origin to point at 
> the feed/head id, it wouldn't make sense to have an origin element in 
> a feed that doesn't have a feed/head id, when that entry is in fact in 
> its origin feed (the non-synthetic case). I think my first reply to 
> Norm stands.

Isn't the sane thing to do to point to the address of the actual feed?

Beyond that, maybe you could include other data too:

<entry>
   <origin href="url of feed">
     <id>id of feed</id>
     <link rel="alternate" type="text/html" 
href="http://www.example.org/feed/" />
</entry>

Anyway, as others have mentioned, because there can be more than one 
link@alternated in a feed, the current wording is nonsensical.

(also, why bother saying "character for character"? Surely, to be the 
same address, it has to be the same characters?)

Graham

---

From: Walter Underwood <[email-masked]>
Date: Tue, 20 Jul 2004 14:53:47 -0700

> providing a default if it isn't specified?

To satisfy causality, it would need to be equal to the earlier of
atom:modified and atom:issued. It could not have been created at
a later date than it was issued or modified.

wunder

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 20 Jul 2004 23:06:56 +0100

> Isn't the sane thing to do to point to the address of the actual feed?

Not really, unless we add words about origin only appearing when id 
does (co-occurence constraint - yuck).

> href="http://www.example.org/feed/" />

Featuritis objection ;)

> link@alternated in a feed, the current wording is nonsensical.

I think this is telling us more about the sense or not of our 
identity model than anything else. We have mandated ids for entries 
but not for feeds. What's that about?

> same address, it has to be the same characters?)

With URIs, not neccessarily, but that's a different matter.

cheers
Bill

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 01:44:21 +0200

> providing a default if it isn't specified?

Not really, imho. I thought we were slowly but steadily moving away from  
default values. If so, this is one of the default values we should get rid  
of. If something's missing, it's... Missing. Null. Nothing. Zip. Zilch.  
Nothing else.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 16:56:30 -0400

> does (co-occurence constraint - yuck).

I don't understand. Surely if we made origin contain the address of the 
feed where the entry was found, the id would never enter into it?

> I think this is telling us more about the sense or not of our identity 
> model than anything else. We have mandated ids for entries but not for 
> feeds. What's that about?

The much narrower use case, I presume.

> With URIs, not neccessarily, but that's a different matter.

Well OK. What's wrong with it being the same address made out of 
different characters?

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 21 Jul 2004 22:24:31 +0100

> feed where the entry was found, the id would never enter into it?

That's ok, I don't understand either - what bit of the format do you 
mean by address?

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Fri, 23 Jul 2004 14:29:44 -0400

/ Graham <[email-masked]> was heard to say:
|> With URIs, not neccessarily, but that's a different matter.
|
| Well OK. What's wrong with it being the same address made out of
| different characters?

There's no easy, reliable way for software to tell that it's the same.

Consider "http://norman.walsh.name/atom/whatsnew.xml" on the one hand and

(1) "http://norman.walsh.name/atom/whatsnew.xml" on the other. They're the same.
    There isn't going to be any disagreement about that.

(2) "http://Norman.Walsh.name/atom/whatsnew.xml" on the other. In order to know
    that they're the same, you have to understand the spec for the 'http' scheme,
    parse the domain component, normalize it, etc. Some folks are going to do
    strncmp() and some aren't so there will be disagreement.

(3) "http://norman.walsh.name/atom/wh%61tsnew.xml" on the other. This is probably
    the same, but that depends on which character(s) are percent escaped. And
    on the scheme. We don't want to go there.

(4) "http://norman.walsh.name/atom%2fwhatsnew.xml" on the other. I believe that
    this is really different, but I might be wrong.

And I haven't even opened the I18N can of worms yet.

If we're going to have semantics that depend on comparing URIs, I do
want the spec to say explicitly that comparison is by comparing the
characters exactly as they are writ.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The trip doesn't exist that can set you
http://nwalsh.com/            | beyond the reach of cravings, fits of
                              | temper, or fears. If it did, the human
                              | race would be off there in a body.--
                              | Seneca

---

From: Norman Walsh <[email-masked]>
Date: Fri, 23 Jul 2004 14:31:43 -0400

/ Walter Underwood <[email-masked]> was heard to say:
| If we want structured names, we start with the X.500 name system
| (above) and also look at AACR2 (library cataloguing rules).
| Anything short of that is US-centric hacks.

That sounds like an argument for unstructured names to me :-)

(Not the US-centric bit, just the fact that getting the markup right
is very, very hard and will add significantly to the complexity of our
spec for very little payoff. IMHO.)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Nothing ever becomes real till it is
http://nwalsh.com/            | experienced--even a proverb is no
                              | proverb to you until your life has
                              | illustrated it.-- Keats

---

From: Sam Ruby <[email-masked]>
Date: Fri, 23 Jul 2004 14:55:57 -0400

> characters exactly as they are writ.

Norman, can you take a look at:

    http://www.intertwingly.net/wiki/pie/PaceFeedEquivalence

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Fri, 23 Jul 2004 15:54:02 -0400

+1

Something like this:

"URI[RFC2396] strings in Atom documents appear as attribute values. URIs can
be tested for equivalence by comparing the normalized values[0] of the
attributes they appear in. URIs MUST NOT be considered equivalent if they
appear in attributes with differing normalized value properties. [1]"

[0] http://www.w3.org/TR/REC-xml/#AVNormalize
[1] http://www.w3.org/TR/xml-infoset/#infoitem.attribute

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Fri, 23 Jul 2004 16:15:14 -0400

/ Sam Ruby <[email-masked]> was heard to say:
| Norman Walsh wrote:
|
|   > If we're going to have semantics that depend on comparing URIs, I do
|> want the spec to say explicitly that comparison is by comparing the
|> characters exactly as they are writ.
|
| Norman, can you take a look at:
|
|     http://www.intertwingly.net/wiki/pie/PaceFeedEquivalence

Yes, that's what I had in mind, assuming we get consensus on the
clarification that I added to that page :-)

  NormanWalsh suggests that "matches" and "matching" be more
  specifically defined as per Section 6.2.1 "Simple String Comparison"
  of 2396bis.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The stone fell on the pitcher? Woe to
http://nwalsh.com/            | the pitcher. The pitcher fell on the
                              | stone? Woe to the pitcher.--Rabbinic
                              | Saying

---

From: Ken MacLeod <[email-masked]>
Date: 27 Jul 2004 09:55:44 -0500

Norman Walsh <[email-masked]> writes:

> |    The "atom:feed" element is the document (i.e., top-level)
> |    element of an Atom Feed Document, acting as a container for
> |    metadata and data associated with the feed.  Its first element
> |    child MUST be atom:head, which MAY be followed zero or more
> |    atom:entry child elements.
> 
> I don't think this description goes far enough to forbid text
> content in atom:feed, which I think should be forbidden. Do we agree
> it should be forbidden?

+1, but I note that there are several constructs where text should not
be allowed.  Can we make a general requirement in "2. Atom Documents",
where we provide general XML processing, that text is *only* allowed
where explicitly specified?

  -- Ken

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 27 Jul 2004 21:31:17 -0400

+1

    -joe