Subject: Consensus call on last round of Paces

From: Tim Bray <[email-masked]>
Date: Tue, 15 Feb 2005 11:12:48 -0800

Methodology: Paul & I went through *all* the WG emails that directly 
commented on the currently open issues (see 
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList); in most cases 
the calls were pretty clear.  As always, we may have mis-read the 
group, feel free to say so if you think so.

The intent is that this email serve as guidance for the editors in 
preparing the format draft that we send out for IETF last call.  We do 
not expect further material discussion of format-related Paces, it's 
now over to the whole IETF.  On the other hand, discussion of editorial 
changes is always fair game, please keep reporting what you find to the 
list, and we wouldn't be surprised if the editors turned up some corner 
cases too.

PaceAggregationDocument & PaceAggregationDocument2
One -1, nobody unambiguously in favor.
DISPOSITION: Close them.

PaceAggregationInSeparateSpec
Only a couple of voices in favor, some support conditional on profiles.
DISPOSITION: Close it, but given that the other aggregation-related 
Paces seem to be failing, it seems like a separate spec is the only 
place that this kind of work gets done.

PaceArchiveDocument
A howling mob of sharp pointy -1's.
DISPOSITION: Close it.

PaceClarifyDateUpdated
A couple of -1's, one fuzzy +1.
DISPOSITION: Close it.

PaceCollection
One pro, one contra, not much discussion.
DISPOSITION: Not enough support, close it.

PaceCommentFeeds
Two contra, one pro, some suggestion that we really need 
link/@rel="comment".
DISPOSITION: Not enough support, close it.

PaceDatesXSD
Everyone seems to like it, enough people want the regex that it's 
accepted too.
DISPOSITION: Accepted, Sayre suggested good wording calling in all the 
specs that are covered.

PaceEntriesElement
Drowning in -1's.
DISPOSITION: Close it.

PaceEntryOrder
One -1, but overwhelming support otherwise.
DISPOSITION: Accepted.

PaceExtensionConstruct
One -1, 1.5 +1's.
DISPOSITION: Not enough support, close it.

PaceFeedRecursive
Lots of -1's.
DISPOSITION: Close it.

PaceFeedState
Lots of -1's.
DISPOSITION: Close it.

PaceNoFeedState
A few +1's, nothing negative.
DISPOSITION: Accepted.

PaceFormatSecurity
Evenly split +1's and -1's.
DISPOSITION: No consensus and we have PaceSecuritySection, close it.

PaceHeadless
Lots of talk, more -1's than +1's.
DISPOSITION: No consensus, close it.

PaceIconAndImage
One -1, but broad support otherwise.
DISPOSITION: Accepted.

PaceLangSpecific
Not a lot of discussion, but pretty positive.
DISPOSITION: Borderline, but accepted.

PaceLinkEnclosure
A little bit of support, but with reservations.
DISPOSITION: A messy Pace and not enough support, close it.

PaceLinkRelVia
Moderate support, no objections.
DISPOSITION: Borderline, but accepted.

PaceMultipleImages
Lots of -1's.
DISPOSITION: Close it.

PaceMustBeWellFormed
Very little discussion, no unambiguous support.
DISPOSITION: Our longest-lived Pace is finally closed.

PaceOrderSpecAlphabetically
A bit of support, not much talk.
DISPOSITION: This is editorial, let the editors run with it.

PaceProfile
Changed along the way, quite a few +1's but even more -1's.  A certain 
amount of "+1 on concept, -1 on syntax" which doesn't help.
DISPOSITION: No consensus, close it.

PaceProfileAttribute
No significant support.
DISPOSITION: Close it

PaceRemoveInfoAndHost
Not much discussion, but no opposition.
DISPOSITION: Borderline, but accepted.

PaceRemoveVersionAttribute
Quite a bit of support, quite a bit of grumbling but no loud -1's.
DISPOSITION: Borderline, but accepted.

PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it.  But now we have a problem, in 
that this removed ambiguity in one direction, just closing it leaves 
the ambiguity.  So the only logical conclusion is that the WG is 
directing the editors to put language in that explicitly forbids 
entries with duplicate <atom:id> in an <atom:feed>.

PaceSecuritySection
More support than opposition, but some feeling that the IETF is going 
to make us do something like this anyhow.
DISPOSITION: Borderline, but accepted.

PaceTextRules
Only one (positive) comment.
DISPOSITION: Not enough support, close it.

PaceXhtmlNamespaceDiv
This is tough.  There are some people who are really against this and 
who aren't moving.  On the other hand, there are way more who are in 
favor.  Reviewing the discussion, the contras are saying that this is 
sloppy and unnecessary and if it solves a problem, that problem really 
shouldn't be there, but they don't seem to be saying it's actively 
harmful.  But the people in favor are arguing that this will reduce 
errors and improve interop.  Also, the Pace was changed in midstream.  
Also, Paul thinks we will get feedback on this from out there in the 
IETF.
DISPOSITION: Borderline, but accepted.

===================================

None-Pace discussion items:

Remove Protocol stuff? See 
http://www.imc.org/atom-syntax/mail-archive/msg13431.html
Several +1's, some grumbling.
DISPOSITION: Let's do it; Paul thinks we'll get IETF feedback on this.

s/tagline/subtitle/ had unanimous support, says Parks: 
http://www.imc.org/atom-syntax/mail-archive/msg13452.html, and no 
push-back
DISPOSITION: Do it.

---

From: Henry Story <[email-masked]>
Date: Tue, 15 Feb 2005 20:38:39 +0100

> entries with duplicate <atom:id> in an <atom:feed>.

Mhh. First off that pace does not speak about allowing more than one id 
per entry, but rather of allowing more than one entry with the same id 
in a feed
document.

Secondly clarifying the spec the way you are doing does not take into 
consideration the consequences of doing so. These consequences include
many other paces which have received many -1s for many reasons. But the 
main
consequence is that the spec will not be finished in time, as you will 
be opening
the debate of archive formats. Allowing this pace through, solves the 
archive
problem that is required by the Atom Charter.

I think there should be serious discussion of why this Pace is not 
thought
to be appropriate. I don't think there are ANY good arguments against 
it.

Henry Story

---

From: Walter Underwood <[email-masked]>
Date: Tue, 15 Feb 2005 11:48:03 -0800

> One -1, but overwhelming support otherwise.

I was the -1, and there is an open issue here. Accepting this means
that Atom cannot represent RSS 1.0 feeds. Is that OK? If so, where
do we state that in the spec?

As far as I know, this is the only exception to interoperability with
other RSS formats.

This also means that Atom cannot be used for BBC News, where order
is significant and non-chronological.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Robert Sayre <[email-masked]>
Date: Tue, 15 Feb 2005 14:52:32 -0500

> DISPOSITION: Borderline, but accepted.

These three are tied together. Note that the second half of PaceHeadless 
is basically the same idea as PaceExtensionConstruct, and all of the 
objections to PaceHeadless centered around the name "feeder" and two -1s 
  wrt to removing Atom head. Also, I count more +1s than -1s. 
PaceLangSpecific is pretty pointless without PaceExtensionConstruct, and 
so is the RDF mapping the chairs would supposedly take on as a product 
of this WG.

> DISPOSITION: A messy Pace and not enough support, close it.

You're kidding, right? I can already here the chants. "OMG ATOM DOESN'T 
DO PODCASTING LOL"

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Feb 2005 11:55:22 -0800

> DISPOSITION: No consensus, close it.

It would be nice if folks would actually comment in detail on these. 
They really have not been adequately discussed. It would be helpful if 
those who are -1 to the idea of profiles could offer a bit more insight 
into their positions.

If you're +1 to the concept, but -1 to the syntax, what syntax do you 
think is better?

If you're -1 to the concept, why?

   - If you just don't think it is necessary, fair enough
   - If you just think it's not part of the core and can be added later,
     fair enough, but that doesn't get around the fact that the current
     spec, as written, does not allow extensions to change containment
     requirements and therefore does not provide for a necessary aspect
     of profile support (the ability to change containment requirements)
   - If you like profiles in general, but don't like the conceptual
     definition in either the PaceProfile or PaceProfileAttribute
     proposals, what should be changed?

- James M Snell

Tim Bray wrote:

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 15 Feb 2005 20:56:24 +0100

Walter Underwood wrote:
> This also means that Atom cannot be used for BBC News, where order is
> significant and non-chronological.

Could you elaborate on that?

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

---

From: Tim Bray <[email-masked]>
Date: Tue, 15 Feb 2005 12:01:40 -0800

On Feb 15, 2005, at 11:52 AM, Robert Sayre wrote:

> You're kidding, right? I can already here the chants. "OMG ATOM 
> DOESN'T DO PODCASTING LOL"

Uh, we already accepted PaceEnclosuresAndPix I think.  This was (I 
believe) trying to change the name from "Enclosure" to "Attachment".  
Or did we screw up?  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 15 Feb 2005 15:02:20 -0500

Tim Bray wrote:
> believe) trying to change the name from "Enclosure" to "Attachment".  Or 
> did we screw up? 

No, I screwed up. Sorry.

Robert Sayre

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 15 Feb 2005 21:05:23 +0100

Tim Bray wrote:
> Also, Paul thinks we will get feedback on this from out there in the IETF.

I'm still not sure how it would improve interop, especially since the 
place the namespace can be defined is optional. I do not think those 
"Planet aggregators" would handle the following correct for example:

  <atom:entry xmlns:atom="..." xmlns:b="http://www.w3.org/1999/xhtml">
   <atom:content type="XHTML">
    <b:div>
     Foo <b:br />
     Et cetera.
    ...

Also, this restriction can be avoided by using |type="application/xml"| 
or |type="application/xhtml+xml"| I assume? (Although that is probably 
not valid for the TITLE or SUMMARY element (it should be).)

---

From: Walter Underwood <[email-masked]>
Date: Tue, 15 Feb 2005 12:09:12 -0800

> Could you elaborate on that?

The BBC News feeds are ordered by "importance", not date. Since the order
is not significant, intermediate nodes could re-order the feed and be
perfectly legal Atom processors.

A publishing date order can be recovered from the date information in Atom.
Other orders cannot.

wunder

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 15 Feb 2005 21:21:42 +0100

Walter Underwood wrote:
>>> This also means that Atom cannot be used for BBC News, where 
>>> order is significant and non-chronological.
>> 
> The BBC News feeds are ordered by "importance", not date. Since the 
> order is not significant, intermediate nodes could re-order the feed 
> and be perfectly legal Atom processors.
> 
> A publishing date order can be recovered from the date information in
> Atom. Other orders cannot.

I think that ordering by importance asks for some kind of semantic
adjustment. It should not have impact on the order in which entries appear.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 15 Feb 2005 20:44:51 +0000

>   - If you just don't think it is necessary, fair enough

It has yet to been explained to me why they might be necessary - so why 
do I need to think they're not necessary to justify an objection? ;)

I've also made a (I believe significant) point in conflating @profile to 
@rel that hasn't been addressed (imho).  The very useful thing I've seen 
is that @profile could be used to flag an archive. But how that's 
essentially different from using @rel I don't know.

And I still don't understand why @version and @profile have anything to 
do with each other.

>     of profile support (the ability to change containment requirements)

I don't see that as a feature as things stand, this idea that a piece of 
metadata can/should alter cardinality or some other aspect of the 
grammar. Give me a sound set of evaluation rules and what you're asking 
for is probably cool. Without them, no.

In another thread, you mentioned that profiling is not difficult, wrt 
conflict resolution. I think you have to think of that difficulty with 
respect to things like Sam's <div> approach to XHTML or wf feed XML. 
What you're asking for here seems to hold a higher bar than what is 
needed for either of those - in particular it won't surprise me if 
conflict resolution requires programming with exceptions or heuristics 
in the absence of people willing to write conflict solvers.

My general opinion on this type of stuff, is that if you can't determine 
sound evaluation rules, it has to be because the domain or the nature of 
the data dictates it - in this case I think vagueness on conflict 
resolution is an indicator that the feature being proposed is woolly. A 
resulting suspicion is that @profile metadata will be highly lossy in 
heavy aggregation and remixing scenarios, which I speculate will explode 
over the next 18 months. In short I'm concerned @profile is feature that 
will not self-interoperate.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Feb 2005 18:50:52 -0800

> do I need to think they're not necessary to justify an objection? ;)

Heh.. that's fair ;-)

> essentially different from using @rel I don't know.

I am a firm believer in giving individual meaningful names to things. 
@rel works for links because it identifies how the link [@rel]ates to 
the item containing the link.  How is @rel meaningful in the case of 
profiles?  I don't believe in reusing names simply because the thing 
being named is somewhat similar to another thing.

> And I still don't understand why @version and @profile have anything to 

I personally don't think @version is all that useful as it is currently 
defined.  What use is it?  What technical problem does @version satisfy?

> will not self-interoperate.

I don't see how the conflict resolution approach I suggested is vague. 
Profiles are evaluated independently.  If multiple profiles are 
specified, each is validated independently of the other.  Yes, this is 
different than what I wrote up in the PaceProfileAttribute but I've come 
to my senses (somewhat) since then.

In any case, I definitely want to avoid getting too hyped up about this. 
  Personally I think profiles would be a good thing, but, it does not 
appear that I am in the majority party on this one.  So be it.

- James M Snell

---

From: Martin Duerst <[email-masked]>
Date: Wed, 16 Feb 2005 14:18:01 +0900

[I appologize that this comes late. I was ill last week.]

I'm also still not convinced about this one. It was introduced
with a very good motivation, namely that it would increase the
chance that namespaces would be used correctly. After the changes,
what I understand is left is the following:

Everybody has to use an XHTML <div> in every atom <content> of
type "XHTML", just to make sure that Sam (any others?) can
realize his dream of "atom without namespace prefixes".

This despite the fact that those that want to avoid any and
all namespace prefixes can use a <div> on their own if they
want. As Sam explained, the <div> in that case would be part
of the content. That's true, but while adding a <div> formally
changes the content, it doesn't actually change the content,
because <div> is just a dummy wrapper, in particular if there
are no other attributes than the default namespace
declaration.

On more general terms, I have observed different choices of
how different namespaces get put together over the last
three if not more years. For the simple case of "namespace
B in namespace A", a variety of choices, with a variety of
reasons, has been proposed.

On the outer side (namespace A), the choices range from
"foreign namespace stuff can be inserted pretty much anywhere
where it makes sense, just put it in" to "we have a '<foreignstuff>'
element, anything from another namespace has to go in there".

On the inner side (namespace B), the choices again range
from "any B element can be used" to "only a wrapper element
can be used".

As an example, SVG tends to high explicity on both sides,
for the inner side, see "included document fragments"
(http://www.w3.org/TR/SVG11/conform#ConformingSVGIncludedDocuments),
for the outer side, see <foreignObject>
(http://www.w3.org/TR/SVG11/extend#ForeignObjectElement).
Most of the motivation for this explicitness in SVG comes from
the fact that without being clear on coordinates/placement/size,
things won't work.

Looking at these cases, it seems to me that what we are doing
with <div> is really thinly motivated (no need for any special
information such as coordinates), and is also in a way abusing
<div>, which was created to indicate divisions in HTML documents,
not to serve as a throw-away default namespace holder in foreign
document formats. Actually, instead of <div>, we could as well
define that we use <body>, or we could even define that we use
something new like <wrapper>. Because as it turns out, while this
element is in the XHTML namespace, it's never part of an XHTML
fragment that an XHTML processor would see.

 >> This is tough.  There are some people who are really against this and 
who aren't moving.  On the other hand, there are way more who are in favor. 
Reviewing the discussion, the contras are saying that this is sloppy and 
unnecessary and if it solves a problem, that problem really shouldn't be 
there, but they don't seem to be saying it's actively harmful.  But the 
people in favor are arguing that this will reduce errors and improve 
interop.  Also, the Pace was changed in midstream.
 >> Also, Paul thinks we will get feedback on this from out there in the IETF.

I'm not sure I understand this sentence. Does Paul think that we will
get feedback in the IETF to put it in anyway, so we better already
put it in? Or that we'll get feedback to take that out in the IETF
so we can as well leave it in for the moment? Or what?

Regards,    Martin.

 >Also, this restriction can be avoided by using |type="application/xml"| 
or |type="application/xhtml+xml"| I assume? (Although that is probably not 
valid for the TITLE or SUMMARY element (it should be).)

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Feb 2005 09:19:18 +0100

For the record: I agree with Martin's analysis.

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Wed, 16 Feb 2005 03:53:32 -0500

> realize his dream of "atom without namespace prefixes".

This is how I generate my Atom 0.3 feed, using the popular Movable Type 
program:

<content type="text/html"
          mode="escaped"
          xml:lang="en"
          xml:base="<$MTBlogURL encode_xml="1"$>">
   <$MTEntryBody encode_xml="1"$>
</content>

I enter the "EntryBody" in an HTML form, by hand. Then, a Perl script 
runs through the template I excerpted above, and generates the feed. The 
template approach is neat, because it lets only slighty technical users 
modify their content with a lot of flexibility and power.

Is this a smart way to generate XML from a purely technical perspective? 
Probably not. Do you and Julian and Anne and Henri approve? Probably 
not. Will tools stop generating feeds this way in the forseeable future? 
Probably not.

My homepage is valid XHTML[0], as are lots of folks'. They are going to 
take their PHP, Perl, Python, JavaScript, and Visual Basic, and use the 
basic string functions of those languages to cobble together a feed. 
They are probably going to go with "XHTML" for ease. They are not going 
to get the namespace right at first, so they are going to add a div 
element around the outside. However, this is not going to reflect what's 
in MySQL.

Robert Sayre

[0] http://validator.w3.org/check?uri=http%3A%2F%2Ffranklinmint.fm

---

From: Martin Duerst <[email-masked]>
Date: Wed, 16 Feb 2005 18:45:35 +0900

Hello Robert,

I'm not sure I understand your point(s) from your mail below.

At 17:53 05/02/16, Robert Sayre wrote:

 >This is how I generate my Atom 0.3 feed, using the popular Movable Type program:
 >

Not a single namespace declaration here, so it's rather
unclear to me what's going on (except if this is an
explicitly wrong example, in which case I don't understand
why it is here, because we know people get things wrong
without needing examples.

No problem with that in principle.

 >Is this a smart way to generate XML from a purely technical perspective?

As long as it's XML and otherwise conformant, I think it's fine.

 >Probably not. Do you and Julian and Anne and Henri approve?

I don't see how I would want to complain about how you generate
your stuff, as long as the result is following the specs.

 >Probably not. Will tools stop generating feeds this way in the forseeable 
future? Probably not.
take their PHP, Perl, Python, JavaScript, and Visual Basic, and use the 
basic string functions of those languages to cobble together a feed. They 
are probably going to go with "XHTML" for ease. They are not going to get 
the namespace right at first, so they are going to add a div element around 
the outside.

All fine. I don't have any problem if they get here. If they add a <div>
to get the namespaces stuff right, great. If they figure out that
they can use an explicit atom: prefix in the template, and declare
the html namespace as default, also great. There are many ways to
get namespaces right, even in a simple template/concatenation
implementation.

 >However, this is not going to reflect what's in MySQL.

Does it need to? Could anybody except for you check?
Should anybody (including you) care? Is it part of conformance?

Regards,     Martin.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 16 Feb 2005 10:03:49 +0000

> without needing examples.

Martin,

Rob probably has a feed root element as follows

<feed
    version="0.3"
    xmlns="http://purl.org/atom/ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xml:lang="en">

ie the feed is served using a default ns (I'm not sure whether you can 
alter this in MT without altering MT).

> your stuff, as long as the result is following the specs.

The point I'm seeing here is that creating markup using string concats 
is inherently fragile. No surpise there. Wrt namespaces, fragility is 
eliminated when you stop using  defaults (but there are other 
considerations which keep string concat fragile). Use of div covers off 
the XHTML case.

cheers
Bill

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 16 Feb 2005 11:35:16 +0100

Bill de hÓra wrote:
>>> Do you and Julian and Anne and Henri approve?
>>

IMHO you are better of using HTML in such cases. Since you can not 
guarentee that your input and therefore your output will always be 
well-formed XML.

And, now I look at it, Robert is using HTML (the text/html MIME type 
implies that) so I do not see the problem.

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 16 Feb 2005 21:08:26 +0200

>   <$MTEntryBody encode_xml="1"$>

How's that relevant wrt. type='XHTML'? If you doubt the robustness of 
concatenation with XHTML, why wouldn't you keep using "entity-encoded 
HTML"?

(FWIW, I don't believe the pace removes the telescoping divs issue. I 
predict the div as part of the envelope is unintuitive to the 
ViewSourceClan, who will assume everything in the Atom namespace is 
part of the envelope and everything in the XHTML namespace is part of 
the payload.)

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

---

From: Robert Sayre <[email-masked]>
Date: Wed, 16 Feb 2005 17:18:56 -0500

>> implies that) so I do not see the problem.

Anne, Henri: thank you for missing the point.

>> Should anybody (including you) care? Is it part of conformance?

Yes. No. Yes. Yes.

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 10:20:36 +0900

At 19:03 05/02/16, Bill de hモra wrote:

 >The point I'm seeing here is that creating markup using string concats is 
inherently fragile. No surpise there. Wrt namespaces, fragility is 
eliminated when you stop using  defaults (but there are other 
considerations which keep string concat fragile). Use of div covers off the 
XHTML case.

Yes, use of div covers that case. But that doesn't mean that if
some people want to use div, everybody has to use div.

Regards,    Martin.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 17 Feb 2005 08:52:09 +0200

>>> Should anybody (including you) care? Is it part of conformance?

Why does the feed have to reflect what is in MySQL? What if you had 
Markdown content (or similar non-(X)HTML) in MySQL?

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

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 17 Feb 2005 11:44:28 +0000

> some people want to use div, everybody has to use div.

It does (I've never said otherwise) - there is a div tax.

cheers
Bill

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 21:57:04 +0900

At 20:44 05/02/17, Bill de h〓ra wrote:
 >
 >Martin Duerst wrote:
 >> At 19:03 05/02/16, Bill de h繝「ra wrote:

 >>  >The point I'm seeing here is that creating markup using string 
concats is inherently fragile. No surpise there. Wrt namespaces, fragility 
is eliminated when you stop using  defaults (but there are other 
considerations which keep string concat fragile). Use of div covers off the 
XHTML case.
 >It does (I've never said otherwise) - there is a div tax.

I'm okay with those paying div tax who think they need a div.
I'm not okay with everybody paying div tax for no apparent
general benefit.

Regards,    Martin.

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 17 Feb 2005 13:09:13 +0000

Martin Duerst wrote:
> concats is inherently fragile. No surpise there. Wrt namespaces, 
> fragility is eliminated when you stop using  defaults (but there are 
> other considerations which keep string concat fragile). Use of div 
> covers off the XHTML case.

I should qualify this tax idea.

1. About Rob's example from MT; the point is twofold a) that what the 
tool provides ootb, b) we can't expect everyone understand the issue as 
well as Rob or we do. Asking questions about how he has his blog setup 
is missing the point. The point is how we expect Atom to help the other 
5 million users generate sound feeds.

2. As things stand there's tradeoff here between robustness and markup 
generation.

4. The general benefit implied by the pace is a reduced amount of 
garbage content.

3. As I've said before the answer to this issue is to stop Atom going 
out in a default namespace as they are actively harmful. That is the 
most cost-effective and general useful solution.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Thu, 17 Feb 2005 20:31:03 +0100

I should emphasize that there are in fact deeper problems
with trying to limit the number of entries with the same id
to one per document.  The notion of an id that this entails,
which in another mail I have called the equivalence relation id,
in fact makes the whole notion of feeds chained by "next" and
"previous" links inconsistent.

This will create a really deep flaw in Atom.

Therefore I think the conclusion that the group has decided not
only against PaceRepeatIdInDocument but furthermore for a
restriction is a understandable but very dangerous conclusion
to come to.

sincerely,

	Henry Story

On 15 Feb 2005, at 20:38, Henry Story wrote:
> Mhh. First off that pace does not speak about allowing more than one 
> id per entry, but rather of allowing more than one entry with the same 
> id in a feed
> document.
>
> many other paces which have received many -1s for many reasons. But 
> the main

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 18 Feb 2005 00:22:50 +0200

On Feb 17, 2005, at 15:09, Bill de hÓra wrote:

> tool provides ootb

Wasn't that what type='HTML' was for?

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

---

From: Henry Story <[email-masked]>
Date: Fri, 18 Feb 2005 17:52:39 +0100

Sorry for replying to my own posts. This problem is a little tricky.

Another way of looking at the problem is that the proposed limitation
is the same as  thinking of id as an entry version identifier. This
interpretation of the id had I thought been rejected by many in the 
past.

I think that resolving what the id construct is by fiat in favor of the 
functional id or the equivalence id interpretation of id, cannot be
portrayed as a correct representation of the desires of this group.
Since this group has been split either way the best way to solve the
issue clearly is to allow 2 ids:

	- versionId: this is the equivalence relation id, and there can
		only be one entry with the same id per document.
     - entryId: this is the functional relation id, and there can be
         more than one entry with the same id per document.

This I think would clearly solve the problem by allowing each side of
the debate to have their requirements fulfilled.

Henry Story

On 17 Feb 2005, at 20:31, Henry Story wrote:
>> id per entry, but rather of allowing more than one entry with the 
>> same id in a feed
>> document.
>>
>> consequence is that the spec will not be finished in time, as you 
>> will be opening

---

From: Danny Ayers <[email-masked]>
Date: Sat, 19 Feb 2005 18:41:34 +0100

Hmm, I've been a little distracted, but I thought
PaceExtensionConstruct did get a reasonable amount of support.
+1 from me anyway.

-- 

http://dannyayers.com