Subject: Notes on the latest draft.

From: James Cerra <[email-masked]>
Date: Tue, 19 Jul 2005 22:08:51 -0700 (PDT)

I took some notes while reading the specification.  Not all of them are good 
notes, and I was cranky while writing them.  Still, they do have some issues 
or slightly vague points about the spec from my view point.

Section 1.2:
------------
> http://www.w3.org/2005/Atom

I guess consistancy is not a requirement of the Atom spec.  By convention, 
this should be all lowercase.  Existing software for Atom 0.3 has to be 
recoded for Atom 1.0, so this change has no real cost.  True, URI references 
shouldn't change; however, that only applies to stable resources.  Atom is 
explicitly unstable until standardized.

Section 2:
----------
> Any element defined by this specification MAY have an xml:base attribute.  
> When xml:base is used in an Atom Document, it serves the function described 
> in section 5.1.1 of RFC 3986, establishing the base URI (or IRI) for 
> resolving any relative references found within the effective scope of the 
> xml:base attribute.

xml:base is a broken specification.  At the simplest, it's just a lame attempt 
at abbreviating strings.  However, it solves that problem in the worst 
possible manner.  As the RDF serializations show, what is needed is a 
name/value pair simular to entities or xml namespaces.  In fact, the general 
solution would combine all three.  This is a case where, in an attempt to 
simplify problems by seggerating them into domains (i.e. namespaces, URI 
abbreviations, SGML "compatibility", and others), the solutions actually 
complicate things to the point of absurdity!  Of course, it is too late to fix 
for Atom 1.0, XML 1.0, and others.  :-(

Section 3.1.1.2:
----------------
HTML has many entities predefined.  If you use HTML content, are those 
entities allowed (after being escaped, of course)?  That would make it really 
really hard to normalize to text or XML without doctype processing.  I feel 
that HTML entities other than numeric references, &amp;gt;, &amp;lt;, 
&amp;amp;, &amp;apos;, and &amp;quote; should be depreciated in HTML 
content.

Section 3.1.1.3:
----------------
Atom should explicitly endorse XHTML over HTML as perferred form of 
content.  HTML is just really hard to process compared with XML.

Also, how does Atom interact with HTML 5, XHTML 2, or future versions of 
the specs?  I still say that version or doctype attributes should be allowed 
to solve disambiguities and allow compatibility with future versions of those 
specs.  Public/System identifiers can still be used to identify type without 
validating it - that is why RDF and namespaces work at all.

Section 3.2.2:
--------------
> The "atom:uri" element's content conveys an IRI associated with the person.  
> Person constructs MAY contain an atom:uri element, but MUST NOT contain more 
> than one.  The content of atom:uri in a Person construct MUST be an IRI 
> reference.

There is no reason *not* to change this to "atom:id".  It is lazy and 
dangerous to have an element lie about the type of its content.  Furthermore, 
the whole point of atom:uri is the same as atom:id - to identify the thing 
they refer to (author or entry) - and their content is likewise identical.

Section 3.2.3:
--------------
> The "atom:email" element's content conveys an e-mail address associated with 
> the person.  Person constructs MAY contain an atom:email element, but MUST 
> NOT contain more than one.  Its content MUST conform to the "addr-spec" 
> production in RFC 2822.

OTOH, is there a reason that atom:uri (which should be atom:indentifier) and 
atom:email are not attributes of a person construct?  It is easier to process 
with CSS, but not harder for other processes, if they are attributes.  
Especially if white space is not significant and should be normalized.  Also, 
by making them attributes you get the XML processor to enforce the 
cardinality of these constructs.

Section 4.1.1:
--------------
> * atom:feed elements SHOULD contain one atom:link element with a rel 
>   attribute value of "self".  This is the preferred URI for retrieving Atom 
>   Feed Documents representing this Atom feed.

There is a mistake.  atom:link indentifies things using an IRI not an URI.

Section 4.1.3.3:
----------------
Clarify this point:  This section applies to atom:content when the src 
attribute is not present.  If it is present, then the content of the external 
file must be valid "whatever" depending on mime type you use (of course).  But 
it could be valid HTML with a doctype or valid XHTML with a root "html" 
element.

Section 4.2.5:
--------------
No way of defining the perfered media type of the icon as with links?

Section 4.2.6:
--------------
How does this interact with xml:base?  Are relative atom:ids allowed?  How are 
they compared?  Are entries information resources?  If so, should something 
retrievable be placed at their URI?

Section 4.2.8:
--------------
No way of defining the perfered media type of the logo (or icon) as with links?

Section 7:
----------
> Fragment identifiers: As specified for "application/xml" in RFC 3023, 
>                       section 5.

Based on the language in that section.....  Does this mean that only XPointer 
fragment identifiers are defined for Atom documents?  I'm confused.  What 
would be the meaning of a fragment like:

http://example.com/feed#frag

???

--
Jimmy Cerra
https://nemo.dev.java.net

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

---

From: Eric Scheid <[email-masked]>
Date: Wed, 20 Jul 2005 15:31:09 +1000

> Section 3.2.2:

Are publishers allow to change the value of atom:id for a given person at
any time, like they are allowed to do with atom:uri?

Is dereferenceability important, or is immutability important?

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jul 2005 09:28:23 +0200

* James Cerra <[email-masked]> [2005-07-20 07:20]:
> I took some notes while reading the specification.  Not all of
> them are good notes, and I was cranky while writing them.

Below some comments on your notes; any snipped notes can be
assumed to be ones where I agree with your assessment.

> I guess consistancy is not a requirement of the Atom spec.  By
> convention, this should be all lowercase.  Existing software
> for Atom 0.3 has to be recoded for Atom 1.0, so this change has
> no real cost.

It does – in terms of time, for putting another draft through the
process.

> Section 2:
> ----------
> > Any element defined by this specification MAY have an
> > xml:base attribute.  When xml:base is used in an Atom
> > Document, it serves the function described in section 5.1.1
> > of RFC 3986, establishing the base URI (or IRI) for resolving
> > any relative references found within the effective scope of
> > the xml:base attribute.
> 
> xml:base is a broken specification.

Yes, we are currently having a long discussion about this.

> Section 3.2.2:
> --------------
> > The "atom:uri" element's content conveys an IRI associated
> > with the person.  Person constructs MAY contain an atom:uri
> > element, but MUST NOT contain more than one.  The content of
> > atom:uri in a Person construct MUST be an IRI reference.
> 
> There is no reason *not* to change this to "atom:id".  It is
> lazy and dangerous to have an element lie about the type of its
> content.  Furthermore, the whole point of atom:uri is the same
> as atom:id - to identify the thing they refer to (author or
> entry) - and their content is likewise identical.

This is really a homepage link. It serves a totally different
purpose from atom:id, and using the same term for the two would
be dangerous.

> Section 4.2.6:
> --------------
> How does this interact with xml:base?  Are relative atom:ids
> allowed?  How are they compared?  Are entries information
> resources?  If so, should something retrievable be placed at
> their URI?

Quoting from the spec:

    Its content MUST be an IRI, as defined by [RFC3987]. Note
    that the definition of "IRI" excludes relative references.
    Though the IRI might use a dereferencable scheme, Atom
    Processors MUST NOT assume it can be dereferenced.

In other words, relative IRIs are forbidden and thus no
interaction with xml:base is possible either.

atom:id contains what should be considered an opaque string that
can be compared with other opaque atom:id strings simply by
comparing character-by-character. The language in the spec should
make that reasonably clear.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Graham <[email-masked]>
Date: Wed, 20 Jul 2005 09:51:24 +0100

On 20 Jul 2005, at 6:08 am, James Cerra wrote:

> I feel that HTML entities other than numeric references, &amp;gt;,  
> &amp;lt;,

Disagree. All it needs is a simple look-up table in the HTML parser.

> content.  HTML is just really hard to process compared with XML.

If you say so.

> they refer to (author or entry) - and their content is likewise  

There is no reason to think that it is either unique to an author or  
will be the same for every reference to a particular author. It's a  
useless identifier.

> atom:email are not attributes of a person construct?

To allow easier, consistent extension.

Graham

---

From: James Cerra <[email-masked]>
Date: Wed, 20 Jul 2005 08:09:42 -0700 (PDT)

e, 

> > Section 3.2.2:
> > --------------
> >> The "atom:uri" element's content conveys an IRI associated with the 
> >> person. Person constructs MAY contain an atom:uri element, but MUST 
> >> NOT contain more than one.  The content of atom:uri in a Person 
> >> construct MUST be an IRI reference.
> > 
> > dangerous to have an element lie about the type of its content. 
> > Furthermore, the whole point of atom:uri is the same as atom:id - to 
> > identify the thing they refer to (author or entry) - and their content is 
> > likewise identical.
> 

I think publishers should be allowed to chenge the atom:id of a person for
future feeds/entries as long as past feeds/entries still respect the old
atom:id.  That is, the atom:id is permanent, but a person can have many
permanent atom:ids.  That's one reason for the old-homepage property in DOAP
[1].

[1] http://www-128.ibm.com/developerworks/xml/library/x-osproj2/#h2

---

From: Sjoerd Visscher <[email-masked]>
Date: Wed, 20 Jul 2005 21:15:02 +0200

James Cerra wrote:
> name/value pair simular to entities or xml namespaces.

That's because it is not an attempt at abbreviating strings, but to 
preserve the meaning of relative URIs, when content is used outside of 
its original context.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

---

From: James Cerra <[email-masked]>
Date: Wed, 20 Jul 2005 19:49:27 -0700 (PDT)

Sjoerd Visscher,

> > xml:base is a broken specification.  At the simplest, it's just a lame
> > attempt at abbreviating strings.  However, it solves that problem in the 
> > worst possible manner.  As the RDF serializations show, what is needed is 
> > a name/value pair simular to entities or xml namespaces.
> 

Same thing.  You are framing the question in a manner that hides the problem,
but it's still there.

The meaning of a relative URI string depends on only one thing: the missing URI
string prefix.  That prefix _is_ the context.  That means that preserving the
semantics of the relative URI string means making it equivalent to the prefix
concatenated with the relative part.

IOW the relative URI is an abbreviated string of the full URI.  Thus a solution
for abbreviating strings also solves the problem you indicated but in a more
general manner.

---

From: James Cerra <[email-masked]>
Date: Wed, 20 Jul 2005 20:33:23 -0700 (PDT)

Aristotle Pagaltzis,

Thanks for the clarifications.

> It does – in terms of time, for putting another draft through the

Opposed with the cost of all the spelling errors that the general public will
make?  The cost to fix it now is marginal compared with the cost over decades
of Atom 1.0 feeds.

Individually these changes may not warrent a new draft, but together I think
they warrant inclusion if, for some other reason, a new draft is drafted.

> purpose from atom:id, and using the same term for the two would

You might be right.... but then it should be named atom:homepage.  Calling it
atom:uri is misleading.

I guess my main complaint about Atom right now is that it feels like there is
little consistency with regard to the name and structure of elements.  That
makes it harder for humans to understand than it has to be.  (An important
point I think, since humans create the software and misunderstandings often
create the hardest bugs to work around.)

> interaction with xml:base is possible either.

Oversight on my part.  Got it.

---

From: James Cerra <[email-masked]>
Date: Wed, 20 Jul 2005 20:43:10 -0700 (PDT)

Graham,

> Disagree. All it needs is a simple look-up table in the HTML parser.

In an XSLT-based Atom-to-XHTML processor, that is a large cost when HTML
includes many many many entities.  At least, I think so and have ignored the
problem because I can't think of a good way to solve it.

> > Furthermore,

I agree, but for other reasons (see my reply to Aristotle Pagaltzis).  Still,
calling it atom:uri is a lie by the spec.  Specs should NEVER NEVER lie!

> To allow easier, consistent extension.

OK.

---

From: James M Snell <[email-masked]>
Date: Wed, 20 Jul 2005 20:51:25 -0700

>You might be right.... but then it should be named atom:homepage.  Calling it
It's an arbitrary IRI "associated with the person"... it's most common 
use will be a link to a homepage but that's not the only use for it.  I 
could use it, for instance, to reference a FOAF document that describes 
me.  It's completely up in the air but is not used to unique id the 
individual.  atom:id would be misleading and atom:homepage is not 
general enough.

>create the hardest bugs to work around.)
There are something like 21 elements in the entire namespace. Each with 
very clear descriptions of structure and use.  I'm sorry, I'm not buying 
your argument that the spec is somehow too hard for humans to understand.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 21 Jul 2005 06:22:52 +0200

* James Cerra <[email-masked]> [2005-07-21 05:00]:
> Sjoerd Visscher,
> > That's because it is not an attempt at abbreviating strings,
> > but to preserve the meaning of relative URIs, when content is
> > used outside of its original context.
> 
> Same thing.  You are framing the question in a manner that
> hides the problem, but it's still there.

No, it frames the question in a manner that addresses the purpose
of having the mechanism.

> IOW the relative URI is an abbreviated string of the full URI.
> Thus a solution for abbreviating strings also solves the
> problem you indicated but in a more general manner.

How would that work?

When you copy content from one document to another, relative URIs
need rewriting. Now please tell me all the locations where you
can find machine-readable relative URIs in a HTML document off
the top of your head. If you think it’s possible, consider that
the document may include Javascript which builds URIs
programmatically.

The basic problem adressed by “base URI embedded in content” is
how to copy content from one location to another while preserving
the meaning of relative URIs *without* having to munge the copied
content – because rewriting reliably is impossible.

How should any scheme you’d propose solve this? And is any such
scheme deployable on the web today?

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Wed, 20 Jul 2005 22:42:41 -0600

> No, it frames the question in a manner that addresses the purpose
Right--it frames it in the context created by RFC 3986.  However, since 
this issue is commonly misunderstood, it's likely that xml:base will 
often be used for string abbreviation in the wild--thus, indeed the 
problem is still there.

If anyone doubts that base URIs as defined by RFC 3986 are not intended 
simply for abbreviation, read section 4.4 ("Same-Document References"). 
  The method outlined there for recognizing same-document references 
would be entirely unreliable if base URIs were used to abbreviate 
arbitrary portions of URIs.  It only works if the base URI is an 
address from which the data containing the relative URI can be 
retrieved.  If base URIs are intended for abbreviation convenience, 
then that section of RFC 3986 is completely broken.  My impression is 
that it isn't broken, but says what was intended.

...but now I've forgotten whether anyone has made a concrete suggestion 
about what can be done at this point, and to solve exactly what 
problem. Do I smell another note in the infamous implementers guide?

---

From: Robin Cover <[email-masked]>
Date: Wed, 20 Jul 2005 23:34:39 -0400 (EDT)

> Thanks for the clarifications.

I'm not sure who said "this should be all lowercase" but I don't
understand the concern.  Only programmers will be hand-keying
a namespace. Most programming languages are case sensitive; XML
is case sensitive; if a programmer can't spell, how can s/he be
a successful programmer of XML tools?

Genuinely baffled,

-rcc

--

---

From: Graham <[email-masked]>
Date: Thu, 21 Jul 2005 11:17:06 +0100

> problem because I can't think of a good way to solve it.

Yes, but your proposed solution just requires people at the other end  
of the chain to do the hard work. A common theme in the design of  
Atom is minimizing the amount of work that must be done by publishers  
(of which there are many) vs the amount of work done by processing  
tools (of which there are few, and which are easier to turn into  
common libraries).

Graham

---

From: Dave Pawson <[email-masked]>
Date: Thu, 21 Jul 2005 17:45:30 +0100

> > problem because I can't think of a good way to solve it.

It's not an XSLT problem. The XSLT engine won't see the entities.
The parser may baulk at it, but the XSLT engine won't feel the pain.

I'm happily processing valid atom 1.0 containing XHTML through
a number of stylesheets. No problems, but then again the only 
entities are NCR's.

regards DaveP

---

From: James Cerra <[email-masked]>
Date: Thu, 21 Jul 2005 11:13:05 -0700 (PDT)

A. Pagaltzis,

> A. Pagaltzis wrote:
> > Jim Cerra wrote:
> > > Sjoerd Visscher wrote:
> ...
> How should any scheme you'd propose solve this? And is any such

Of course.  I'll answer backwards.  Using the terminology of your frame of
reference....

I'd solve it in the same manner that XML namespaces solved the multiple context
problem: by providing a default context as well as explicitly named contexts. 
The default context works the same way as xml:base or the the default xmlns
works now.  Explicit contexts would work simular to prefixed namespaces
(xmlns:prefix).

> the top of your head. If you think it's possible, consider that
> The basic problem adressed by "base URI embedded in content" is
> content â€“ because rewriting reliably is impossible.

The same way as now: copying the base URI context[s] from the XML infoset
assocated with the elements being copied.  It is the same way namespaces are
handled now.

---

From: James Cerra <[email-masked]>
Date: Thu, 21 Jul 2005 11:29:33 -0700 (PDT)

Graham,

> tools (of which there are few, and which are easier to turn into  

You are probably correct.  However...

Aren't HTML's character references harder for publishing software to produce
compared with HTML numeric references?  After all, producing numeric references
requires a simple fast algorithm and no lookup table.  Thus, depreciating HTML
character references makes it _easier_ to publish Atom code as well.

The only feed producer software that probably likes HTML character references
above all else are human hands.  And if humans are writing their feeds by hand,
then..........  :-o  (Of course, I'm probably the loser who would actually
write my own feeds by hand!  :-))

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Graham <[email-masked]>
Date: Thu, 21 Jul 2005 19:38:20 +0100

> character references makes it _easier_ to publish Atom code as well.

Not if the HTML in the publishers database already contains named  
references, and/or users are regularly submitting HTML that contains  
named references.

> then.

Feeds a generally a small facet of a much larger publishing system or  
process, that yes, includes humans.

Graham

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 21 Jul 2005 22:04:26 +0200

* James Cerra <[email-masked]> [2005-07-21 20:45]:
> Aren't HTML's character references harder for publishing
> software to produce compared with HTML numeric references?
> […] The only feed producer software that probably likes HTML
> character references above all else are human hands.  And if
> humans are writing their feeds by hand, then..........  :-o

Well, the feed could still be autogenerated even though a human
is writing HTML by hand. Most weblogging systems allow the author
to write his post as HTML. In the simplest case, a feed of such
entries would be automatically generated but would still contain
human-authored HTML.

> (Of course, I'm probably the loser who would actually write my
> own feeds by hand!  :-))

Not really… :-)  I run my weblog by editing a single Atom (0.3 as
of yet, need to convert…) feed that contains all entries ever,
from which a stylesheet generates the public feed and all the
webpages. But I never need to write any entities, since that file
is UTF-8 and I edit it with gvim. (Insert “UTF-8 rocks” fanboy
praise.)

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 21 Jul 2005 13:43:58 -0700

I've been continuing to tweak the comments extension and believe that I 
am nearing a stable enough version to draft up the I-D.  Here's what 
I've got currently:

http://www.snellspace.com/wp/?p=194

There are three link relations:

* http://purl.org/syndication/thread/1.0/comments
* http://purl.org/syndication/thread/1.0/root
* http://purl.org/syndication/thread/1.0/in-reply-to

/comments provides the URL (dereferencable) to an Atom feed that 
contains comment entries and may appear within atom:feed and/or atom:entry
/root provides the URL (dereferencable) to the Atom feed that contains 
the original entries and may appear within atom:feed and/or atom:entry
/in-reply-to provides the atom:id (not dereferencable) of an original 
atom:entry and may appear within atom:feed or atom:entry.  in-reply-to 
on the feed level indicates that all of the entries within the feed are 
considered replies to the identified atom:entry.

all of these link relations may appear more than once (e.g. an entry can 
be a reply to multiple entries from multiple feeds.

Example 1: A weblog with a main feed and a comments feed

    Feed A: Main entry feed
    Feed B: Comments feed

    <!-- Feed A -->
    <feed>
      ...
      <link rel="http://purl.org/syndication/thread/1.0/comments"
              href="http://example.com/feedb.xml" />
      <entry>
        <id>tag:entry:1</id>
        ...
      </entry>
    </feed>

    <!-- Feed B -->
    <feed>
      ...
      <link rel="http://purl.org/syndication/thread/1.0/root"
              href="http://example.com/feeda.xml" />
      <entry>
        <id>tag:entry:1:1</id>
        <link rel="http://purl.org/syndication/thread/1.0/in-reply-to"
                href="tag:entry:1" />
        ...
      </entry>
    </feed>

Example 2: A post on one weblog responds to a post on another weblog

    Feed A: Blog 1 feed
    Feed B: Blog 2 feed

    <!-- Feed A -->
    <feed>
      ...
      <entry>
        <id>tag:blog-a:entry:1</id>
        ...
      </entry>
    </feed>

    <!-- Feed B -->
    <feed>
      ...
      <entry>
        <id>tag:blog-b:entry:1</id>
        <link rel="http://purl.org/syndication/thread/1.0/root"
              href="http://blog-a.com/feeda.xml" />
        <link rel="http://purl.org/syndication/thread/1.0/in-reply-to"
                href="tag:blog-a:entry:1" />
        ...
      </entry>
    </feed>

Feedback requested.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 22 Jul 2005 00:31:51 +0200

> Feedback requested.

I like it so far; comments follow (no pun intended).

> /root provides the URL (dereferencable) to the Atom feed that
> contains the original entries and may appear within atom:feed
> and/or atom:entry

Why is this restricted to being an Atom feed? Shouldn’t @type
govern the precise meaning? Should linking to other kinds of
resources, such as a weblog with the appropriate autodiscovery
tags in its HTML or to a FOAF file, be outlawed? If not, are
there any SHOULD/MUST requirements for linked resources?

> /in-reply-to provides the atom:id (not dereferencable) of an
> original atom:entry and may appear within atom:feed or
> atom:entry. in-reply-to on the feed level indicates that all
> of the entries within the feed are considered replies to the
> identified atom:entry.

Is it legal if it appears at both levels? And what does it mean
then?

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 21 Jul 2005 15:43:38 -0700

>I like it so far; comments follow (no pun intended).
;-)

>there any SHOULD/MUST requirements for linked resources?
The restriction is to make the link predictable and keep the spec 
simple.  For instance, if I linked to anything but an Atom feed, what 
would in-reply-to link to?

>Is it legal if it appears at both levels? And what does it mean
Yes. If the entry level link has the same URI as the feed level link, 
there is no effect... it's basically just redundant data.  If the entry 
level link specifies a different URI, then it's basically an assertion 
that the entry is a response to two different entries.  If all of the 
entries within a feed are replies to the same entry, putting the 
in-reply-to at the feed level simply gives you a shortcut the same way 
that putting atom:author elements at the feed level rather than entry 
level does.

e.g.

1.
<!-- legal but redundant -->
<feed>
  <link rel=".../in-reply-to" href="{url1}" />
  <entry>
    <link rel=".../in-reply-to" href="{url1}" />
  </entry>
</feed>

2.
<!-- equivalent to #3 below -->
<feed>
  <link rel=".../in-reply-to" href="{url1}" />
  <entry>
    <link rel=".../in-reply-to" href="{url2}" />
  </entry>
</feed>

3.
<!-- equivalent to #3 below -->
<feed>
  <entry>
    <link rel=".../in-reply-to" href="{url1}" />
    <link rel=".../in-reply-to" href="{url2}" />
  </entry>
</feed>

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 22 Jul 2005 02:33:35 +0200

* James M Snell <[email-masked]> [2005-07-22 01:25]:
>For instance, if I linked to anything but an Atom feed, what

Still atom:id values. Presumably, any resource linked to is
associated, by whatever means, to the Atom feed containing the
entry being replied to. I don’t know what behaviour would be most
sensible for cases where it’s not an Atom feed and I’m not
advocating trying to specify any. I just think it’s a good idea
to say that the specified expectation, ie that it’s the Atom feed
where the entry being replied to originated, applies only when
@type='application/atom+xml'. That way, if someone else figures
out a sensible thing to do for other cases in the future, they
can extend the same relation rather than needing to specify a new
one.

>If the entry level link specifies a different URI, then it's
>basically an assertion that the entry is a response to two
>different entries.

Ah, the feed-level link simply inherits. Good idea, I like that.

Regards,

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 22 Jul 2005 09:55:09 +0200 (CEST)

>     <link rel=".../in-reply-to" href="{url2}" />

#2 is not how atom:author "inheritance" works (assuming there is some kind
of atom:author inheritance, which is not established). I'd prefer #2 to be
equivalent to this:
<feed>
  <entry>
    <link rel=".../in-reply-to" href="{url2}" />
  </entry>
</feed>

That is, the set of entry level links overrides the set of feed level links.

If I understand correctly, ".../root" tells you where to find the entry
identified with ".../in-reply-to". How are you dealing with multiple
in-reply-to?
<link rel=".../root" href="feeda.xml" />
<link rel=".../root" href="feeda.xml" />
<link rel=".../in-reply-to" href="tag:entry1" />
<link rel=".../in-reply-to" href="tag:entry2" />

If I misunderstood, what is ".../root" for?

-- 
Thomas Broyer

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 22 Jul 2005 13:14:28 +0300

On Jul 20, 2005, at 08:08, James Cerra wrote:

> really hard to normalize to text or XML without doctype processing.

No. You are supposed to use a tag soup parser for HTML. Tag soup 
parsers don't process the DTD. They have a hard-coded table of 
character entities.

> Also, how does Atom interact with HTML 5,

You put the stuff in there and in time clients will adapt?

> I still say that version or doctype attributes should be allowed
> specs.

I am strongly against catering for doctype sniffing on the XHTML side.

> Public/System identifiers can still be used to identify type without
> validating it

No, they cannot. See http://hsivonen.iki.fi/doctype/#xml

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

---

From: James M Snell <[email-masked]>
Date: Fri, 22 Jul 2005 14:01:35 -0700

>of atom:author inheritance, which is not established). I'd prefer #2 to be
Yeah, you're right. bad analogy.

>That is, the set of entry level links overrides the set of feed level links.
Gotta think about this a bit more.  This may be the better approach.

>If I misunderstood, what is ".../root" for?
.../root is simply a link back to feeds that may contain root level 
entries (e.g. the entries being responded to).  In the example, the two 
in-reply-to links could reference entries in either of the two linked 
root feeds.  It's up to the implementation to figure out exactly how to 
handle it.

Again, I'm still stewing over all this so if you have any specific 
suggestions on how to handle it better, please let me know.

- James

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 24 Jul 2005 20:49:44 +0100

> works now.  Explicit contexts would work simular to prefixed namespaces

I suggest reconsidering. It's not clear default namespaces solve
anything and in the places where they don't solve anything they are
hardly likely to be accused of inducing robustness. If the best of two
years on the Atom WG and years of working with XML teaches me anything
it's this - format defaults are surprisingly tricky to get right.

cheers
Bill