Posted PaceLangSpecific

2005-02-07 Thread David Powell

I've posted PaceLangSpecific. It allows the use of xml:lang, but
clarifies which properties are language specific.



== Abstract ==

Allow xml:lang anywhere, but restrict its effects to specific elements
so that it is clear when implementations must preserve the language
context.

== Status ==

Open

Author: DavidPowell


== Rationale ==

xml:lang can appear anywhere and specifies a language for all children
of its containing element. This is simple enough in the context of an
XML document, but in the context of any other model, language tags
need to be explicitly preserved for every property of each entry and
feed.

Many Atom implementations will use RDBMs or object-oriented
implementations, rather than XML DOMs to model and store atom content
internally. In a RDBMs model, each language sensitive field will
require an extra database column. It is clear that some fields, such
as atom:updated, are not language dependant, while others such as
atom:content are. Some fields are grey areas.

This proposal improves interoperability by ensuring that xml:lang is
processed consistently by different implementations. It improves
efficiency by allowing implementations to safely discard the language
context for non-language specific fields.

== Proposal ==

In section 2, replace:

{{{ Any element in an Atom Document MAY have an xml:lang attribute,
whose content indicates the 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. }}}

with:

{{{ Any element in an Atom Document MAY have an xml:lang attribute,
whose content sets the language content for the element and its
children. The language context is only significant for the language
sensitive constructs, which are indicated in this specification.
Implementations MUST preserve the language context of language
sensitive constructs. Requirements regarding the content and
interpretation of xml:lang are specified in XML 1.0
[W3C.REC-xml-20040204] Section 2.12. }}}

In section 3.1, add the sentence:

{{{ Except for the type attribute, the content of Text constructs is
language sensitive. }}}

In section 3.2.1, add the sentence:

{{{ The content of atom:name is language sensitive. }}}

In section 4.6.5, add the sentence:

{{{ The content of the title attribute is language sensitive. }}}

In section 4.13.3, add the sentence:

{{{ The content of the label attribute is language sensitive. }}}

In section 4.15, add the sentence:

{{{ Except for the type and src attributes, the content of
atom:content is language sensitive. }}}



== Impacts ==

Depending on which extension paces are accepted, a statement on the
default language sensitivity of extension elements will need to be
made.



-- 
Dave



Re: Call for final Paces for consideration: deadline imminent

2005-02-07 Thread David Powell


Sunday, February 6, 2005, 3:10:23 AM, you wrote:


 On 6/2/05 4:27 AM, David Powell [EMAIL PROTECTED] wrote:

 Although we could keep the model we have (let's call it the 'mutable entries'
 model), it isn’t  clear on a number of issues.  Eg, if an old version of an
 entry has some property that isn’t  present in a newer version, does that
 property still apply to the new instance?  The answer is presumably 'no' but
 it isn't obvious from the spec.  Under a 'multiple instances' model, it would
 be implicit.

 +1

 now go write a pace, and quickly

 e.

My plan was to take the Atom Concepts section of the document, add
Entry Instance to it, and do a bit of find/replacing to make it
clear that properties are properties of the instance and id is the id
of the Entry itself. Unfortunately there is no Atom Concepts section,
so I have not had time to do this. Currently the only definition of
what an entry or feed is in the informal introduction in the first
couple of sentences of the specification.

I think we should to insert an Atom Concepts section before the
current section 2 so that we can properly explain the important terms
in Atom before we can talk about how to represent them in the format.

Can we fix this as an editorial issue? There is enough confusion about
entries and ids amongst the working group, nevermind the readers.

-- 
Dave



Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Henry Story
On 7 Feb 2005, at 00:09, Roy T. Fielding wrote:
On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote:
* John Panzer [EMAIL PROTECTED] [2005-02-06 13:58-0800]
Since an entry is identified uniquely by its atom:id (though it can  
have
different states at different times);
As I understand the Web, the REST concepts that underpin HTTP
are quite happy with their being multiple representations of
the selfsame resource *at the time*.
Also at multiple times.
Yes, it's all about time, but also about resources.  The entry is
a resource, and that resource may have multiple representations at
a single time (atom, rss1, rss2) and also over different times.
A resource has a single state at one point in time, but may have
different states over time (in some case they must have different
states over time because that is the essence of what makes them
a resource, just as a clock is expected to have different state).
URIs identify resources, not necessarily singular states.
It is about resources, but the question is what the id resource  
identifies.
There are two things the id resource could identify:
  a- the uri of the entry (rdf:about)
  b- a uri related to the entry by the id relation (rdf:resource)

I find interpretation b to be the most powerful one, because it
allows us to narrow the disagreement between both factions down
to the properties of the id relation.
Here is how I model in rdf arrow notation the atom example [1]:
_entry
  |--title- Atom Powered Robots Run Amok
  |--link-- http://example.org/2003/12/13/atom03
  |--id vemmi://example.org/2003/32397
  |-update- 2003-12-13T18:30:02Z^^xsd:dateTime
The differences this group has as to the interpretation of the
id relation can be explained as follows:
  -those that like Bob Wyman and me-currently, believe that id is
   just a functional relation. Call this the [Functional Id] theory.
  -others like Roy Fielding and me-when-I-first-thought-of-the-issue,
   think of id as an equivalence relation  (which I think just means
   that the relation is functional, symmetric and transitive). Call
   this the [Equivalence Id] theory.
Under the [Equivalence ID] theory, the above graph has the following
graph as consequence.
vemmi://example.org/2003/32397
|--title- Atom Powered Robots Run Amok
|--link-- http://example.org/2003/12/13/atom03
|-update- 2003-12-13T18:30:02Z^^xsd:dateTime
The above conclusion cannot be drawn from the [Functional ID]
theory.
Note that both theories:
  - are expressed in terms of resources
  - could easily be compatible: it would just require
distinguishing the [Equivalence ID] relation and the
[Functional ID] relation by naming them differently.
Let us do so now:
[Functional ID] - funcId
[Equivalence ID] - equivId
Feeds are sliding window resources, but their representations
do not slide -- they are fixed at a given point in time.
Yes, I agree. But the time component is only as important as you
say if you emphasize http URIs for your id. But that will come out
more clearly below.
If it is
reasonable to say that, at any single point in time, only one
representation of a given entry can appear in the feed's
representation, then the only valid representation of a feed
is one that does not contain any duplicate entry id's.
This is true only if you have the [Equivalence ID] interpretation
of the id relation. (Ie you think of id as equivId.)
To give a more concrete example let us use the well understood
http URIs for our ids, and let us disambiguate the two id types.
_entry
  |--title--- Atom Powered Robots Run Amok
  |--link-- http://bblfish.net/2005/02/07/entry03/v2/entry.html
  |--funcId-- http://bblfish.net/2005/02/07/entry03/
  |--equivId- http://bblfish.net/2005/02/07/entry03/v2/
  |-update--- 2003-12-13T18:30:02Z^^xsd:dateTime
The file system layout would be something like the following
(taking root at 2005/02/07 to save space)
entry03-- a directory resource pointed to by the funcId uri
entry03/v1 -- a directory resource for the previous entry version
entry03/v1/entry/xml  -- the first entry version of the xml
entry03/v1/entry.html -- the second entry version in html form
entry03/v2 -- a directory resource pointed to by the equivId uri
entry03/v2/entry.xml  -- the second entry version in xml format
entry03/v2/entry.html -- the first entry version in html format
With the above file system layout it would therefore be completely
feasible to have a feed that would correctly state at a precise time
the following:
feed
  entry
titleAtom-Powered Robots Run Amok/title
link href=http://bblfish.net/2005/02/07/entry03/v1/entry.html/
funcIdhttp://bblfish.net/2005/02/07/entry03//id
equivIdhttp://bblfish.net/2005/02/07/entry03/v1//id
updated2003-12-13T18:30:02Z/updated
  /entry
  entry
titleAtom-Powered Robots Run Amok/title
link href=http://bblfish.net/2005/02/07/entry03/v2/entry.html/
funcIdhttp://bblfish.net/2005/02/07/entry03//id
equivIdhttp://bblfish.net/2005/02/07/entry03/v2//id

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Roy T. Fielding
On Feb 6, 2005, at 6:42 PM, Bob Wyman wrote:
Roy T. Fielding wrote:
Aggregators do not consume feed resources -- they consume an
iterative set of overlapping feed representations.
	This is only true of pull based aggregators that poll for feeds.
None of the aggregators that I use are polling based. I use the PubSub
Sidebars and the Gush aggregator built by 2entwine.com. These 
aggregators
consume streams of entries that are pushed to them using the Atom over
HTTP protocol.
No, they consume feed representations of length=1, which contains
an entry representation.  They are neither streams nor entries, and
if we stop confusing the messages received with the rather abstract
notion of what the author considers to be their entry, then it is
much easier to understand what the id tells the recipient.
This is not specific to the transfer protocol.  It is an aspect
of message passing architectures.  Most network-based systems
build tremendously complex synchronization and update mechanisms
in an attempt to make message passing match what an ideal
world would consider reality.  Unfortunately for them, the theory
of relativity is just as applicable to software as it is to us.
HTTP (or at least the use of HTTP based on REST) changes the
perspective by acknowledging that messages are not the same
as what is identified.  It seems a little odd, at first,
but it makes a huge difference because clients stop assuming
that they have a complete understanding, servers supply more
explicit information about what they do send, and the overall
system becomes less brittle during failures. However, HTTP
only tries to match what is already true of message passing --
it does not make the rules.
Regardless of the protocol used to receive an atom feed, the
only things that will actually be received are representations.
Computers can't transfer a temporal mapping that has yet to
be defined.
Roy


Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Henry Story
On 7 Feb 2005, at 13:33, Roy T. Fielding wrote:
If it is
reasonable to say that, at any single point in time, only one
representation of a given entry can appear in the feed's
representation, then the only valid representation of a feed
is one that does not contain any duplicate entry id's.
This is true only if you have the [Equivalence ID] interpretation
of the id relation. (Ie you think of id as equivId.)
Yes, and to make myself perfectly clear, that means functional ID,
as you call it, would conflict with the design of Atom and any
reasonable design of a system wherein the things being identified
are allowed to be updated over time.
I wonder if you read the rest of my message...
I gave an example that did not conflict with a reasonable design.
Here is a reasonable design of the files in a web site for an entry 
with versioning:

entry03-- a directory resource pointed to by the funcId uri
entry03/v1 -- a directory resource for the previous entry version
entry03/v1/entry.xml  -- the first entry version of the xml
entry03/v1/entry.html -- the second entry version in html form
entry03/v2 -- a directory resource pointed to by the equivId uri
entry03/v2/entry.xml  -- the second entry version in xml format
entry03/v2/entry.html -- the first entry version in html format
Here is a reasonable feed corresponding to the above file system
layout of resources:
feed
  entry
titleAtom-Powered Robots Run Amok!/title
link href=http://bblfish.net/2005/02/07/entry03/v1/entry.html/
funcIdhttp://bblfish.net/2005/02/07/entry03//id
equivIdhttp://bblfish.net/2005/02/07/entry03/v1//id
updated2003-12-13T18:30:02Z/updated
  /entry
  entry
titleAtom-Powered Robots Run Amok/title
link href=http://bblfish.net/2005/02/07/entry03/v2/entry.html/
funcIdhttp://bblfish.net/2005/02/07/entry03//id
equivIdhttp://bblfish.net/2005/02/07/entry03/v2//id
updated2003-12-13T18:30:02Z/updated
  /entry
/feed
((It seems to me that when blogging it is very good practice
to keep the changes of one's entries available as above, since
one's changing one's mind on an issue affects the pages and comments
of other people pointing to your entry.))
Anyway, as you see I am agreeing with you that equivId will be
different for each entry in a feed, though funcId is the same.
There we have a feed that contains both notions.
So, please, stop trying to
make a real system fit an artificial model of graph theory that
isn't even capable of describing the Web.  Fix your model instead.
Do you have a good paper that proves your incredibly strong statement
above? I would be happy to understand this position, as it would save
me a lot of time. But I can't just take your word for it, as there
are numerous people who don't seem to think the way you do, and in
just as senior or more senior positions than your are. But perhaps
I have missed some important development recently. (I am not being 
ironic here though it may sound like it. I really would like to
understand more fully your position.)

Henry Story


Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Henry Story

On 7 Feb 2005, at 14:15, Henry Story wrote:
entry03-- a directory resource pointed to by the funcId uri
entry03/v1 -- a directory resource for the previous entry version
entry03/v1/entry.xml  -- the first entry version of the xml
entry03/v1/entry.html -- the second entry version in html form
entry03/v2 -- a directory resource pointed to by the equivId uri
entry03/v2/entry.xml  -- the second entry version in xml format
entry03/v2/entry.html -- the first entry version in html format
Clearly there were a few typos in the above:
entry03-- a directory resource pointed to by the funcId uri
entry03/v1 -- a directory resource for the previous entry version
entry03/v1/entry.xml  -- the first entry version in atom xml
entry03/v1/entry.html -- the first entry version in html format
entry03/v2 -- a directory resource pointed to by the equivId uri
entry03/v2/entry.xml  -- the second entry version in xml format
entry03/v2/entry.html -- the second entry version in html format


Re: PaceDatesXSD

2005-02-07 Thread Norman Walsh
/ Eric Scheid [EMAIL PROTECTED] was heard to say:
| On 6/2/05 9:38 AM, Sam Ruby [EMAIL PROTECTED] wrote:
|
| I am +1 on the regular expression limitation,
| believe that all dates that that conform to this limitation are valid
| RFC 3339 and xsd:dateTime values, and believe that it will interop with
| all of the existing XSD implementations.
|
| where this is the regex? that regex allows this totally bogus value
|
| 2005-13-34T25:65:96+00:65
|
| there are test cases in the validator to check this, but those test cases
| will no longer be supported by the spec and will thus be a bug in the
| validator :-(

I think the proposed constraint was (RFC 3339 or xsd:dateTime) and
matching the regular expression.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | The only thing that makes life possible
http://nwalsh.com/| is permanent, intolerable uncertainty;
  | not knowing what comes next.--Ursula K.
  | LeGuin


pgp7Wp5TIJtTl.pgp
Description: PGP signature


Re: PaceDatesXSD

2005-02-07 Thread Sam Ruby
Norman Walsh wrote:
/ Eric Scheid [EMAIL PROTECTED] was heard to say:
| On 6/2/05 9:38 AM, Sam Ruby [EMAIL PROTECTED] wrote:
|
| I am +1 on the regular expression limitation,
| believe that all dates that that conform to this limitation are valid
| RFC 3339 and xsd:dateTime values, and believe that it will interop with
| all of the existing XSD implementations.
|
| where this is the regex? that regex allows this totally bogus value
|
| 2005-13-34T25:65:96+00:65
|
| there are test cases in the validator to check this, but those test cases
| will no longer be supported by the spec and will thus be a bug in the
| validator :-(
I think the proposed constraint was (RFC 3339 or xsd:dateTime) and
matching the regular expression.
Let's take credit for all four requirements: regular expression, RFC 
3339, xsd:dateTime, and w3cdtf.

I don't know of any valid tool produced dates which would not conform to 
all four, so the requirement on the producer side should not be onerous.

This would enable the widest range of readers.
- Sam Ruby


Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
On Sunday, February 6, 2005, at 09:35  AM, Sam Ruby wrote:
Graham wrote:
On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote:
If you produce feeds that contain multiple entries with the same id, 
there will be people who misunderstand such documents.

I do believe that there needs to be some way to say this is not a 
feed, but an archive.
Solution:
A new atom:archive top level element with normal head and entry 
children. Difference is multiple instances of entries are allowed 
with the same id. Each is distinguished by a new atom:version date, 
that has no semantics other than determining which instance is the 
newest. Meanwhile, atom:version and multiple instances are explicitly 
banned from atom:feed.
?
Works for me.
Presumably, atom:entry elements can have at most one atom:version 
child element.  But, are atom:version elements be required in 
atom:archives?

Okay, so we are punting on defining a way to archive the changing state 
of feed/head.

Making something like the above semi-concrete:
archive
head
...
/head
entry
id revision=3foo:bar/a/id
...
/entry
entry
id revision=2foo:bar/a/id
...
/entry
entry
id revision=1foo:bar/a/id
...
/entry
...
/archive
...where @revision is a number whose only requirement is that the 
number for a later revision be greater than the number for an earlier 
revision, but skipping numbers is allowed.

@revision could go in entry instead of id, or could be revision.
We're at the deadline for paces.  Someone who wants something like this 
should write one today.



Re: PaceJoinSectionSixAndTen

2005-02-07 Thread Paul Hoffman
-1. IETF documents have to have a Security Considerations section 
that describes general security issues. In no cases that I know of do 
they contain protocol specification. See RFC 3552 for more info.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceClarifyDateUpdated

2005-02-07 Thread Walter Underwood

--On February 6, 2005 1:07:42 PM +0200 Henri Sivonen [EMAIL PROTECTED] wrote:

 Yes. Also as a spec expectation--that is, how often is the SHOULD NOT 
 expected
 to be violated. Will the SHOULD NOT be violated so often that it dilutes the
 meaning of all SHOULD NOTs?

Roughly, a SHOULD or SHOULD NOT can be violated when the implementer 
understands and accepts the interoperability limitations they of that
decision.

So, the spec should (must?) explain what those are.

wunder
--
Walter Underwood
Principal Architect, Verity



RE: PaceArchiveDocument posted

2005-02-07 Thread Walter Underwood

I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.

So, it is not possible for the current doc to fulfill the charter, and
this document is not ready for last call.

wunder

--On February 6, 2005 2:00:20 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote:

 
 -1.
   The use cases for archiving have not been well defined or well
 discussed on this list. It is, I believe, inappropriate and unwise to try to
 rush through something this major at the last moment before a pending Last
 Call.
 
   bob wyman
 
 
 



--
Walter Underwood
Principal Architect, Verity



Re: PaceJoinSectionSixAndTen

2005-02-07 Thread Bill de hÓra
Paul Hoffman wrote:
-1. IETF documents have to have a Security Considerations section that 
describes general security issues. In no cases that I know of do they 
contain protocol specification. See RFC 3552 for more info.
Is that -1 to the proposed title or -1 to having one section?
cheers
Bill


Re: PaceArchiveDocument posted

2005-02-07 Thread Robert Sayre
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
We have feed documents. A series of feed documents makes an archive. I 
don't see why we need atom:archive after all.

Robert Sayre


Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Antone Roundy
On Sunday, February 6, 2005, at 07:42  PM, Bob Wyman wrote:
The whole feed business is simply an artifact of the
polling-based model of syndication.
Interesting to hear the architecture for the model that most people use 
today be referred to as an artifact.  But yeah, to someone who 
doesn't used polling aggregators, it would seem so.

The polling oriented, feed-based model of syndication results in
significant waste of network bandwidth
The sliding window view into the historical states of entries (vs. a 
sliding window into the current states of entries) would also waste 
some bandwidth transmitting obsolete entry states, and could result in 
missed entries if someone writing an entry does a lot of tweaking and 
publishes each tweak (thus filling their feed document with versions of 
a single entry), which, though sloppy methodology, is probably not 
entirely uncommon--just my guess.  Polling combined with diffs of the 
current state of entries would use similar bandwidth to push...
and processing resources
...and wouldn't require the server to keep track of all of its 
subscribers, and would result in bandwidth usage being spread over time 
better than push, assuming push servers push new entries out to 
everyone as quickly as possible after they're published.  Both methods 
have their advantages, many more of which could be listed on either 
side, I'm sure.

While the use of push-based aggregators may not be widespread,
it does not make sense, I think, to bind Atom to the inefficient,
high-latency polling model when we know that there is a workable 
alternative
approach -- which is far superior in at least some important 
applications of
syndication.
Agreed.  But I've lost track of what aspect of Atom's architecture you 
are saying is bound to polling at the expense of push.  Are we still 
talking about sliding window vs. current state?  If so, what difference 
does that make to a push-based aggregator?



Re: PaceArchiveDocument posted

2005-02-07 Thread James M Snell
+1.  We need to at least discuss the model a bit more before agreeing to
a syntax.  As with all things, there are many different ways we can do
this -- a new top level elements, the @profile attribute Mark and I have
been pitching, etc -- but unless we identify the general requirements
and a general model that we're shooting for, whatever we scrap together
here at the last minute is not going to be completely adequate.
- James M Snell
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
So, it is not possible for the current doc to fulfill the charter, and
this document is not ready for last call.
wunder
--On February 6, 2005 2:00:20 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote:

-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to try to
rush through something this major at the last moment before a pending Last
Call.
bob wyman



--
Walter Underwood
Principal Architect, Verity




Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 10:06  AM, Robert Sayre wrote:
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
We have feed documents. A series of feed documents makes an archive. I 
don't see why we need atom:archive after all.

If Atom Documents are not allowed to contain multiple instances of a 
particular resource, then archiving the states of an entry would 
require the feed to be split into more, smaller feed documents any time 
an entry is edited without many other entries being published in 
between edits.  For example, if you published an entry, decided to 
revise a paragraph and published again, found a misspelling and 
published again, and then fixed and published another misspelling, 
you'd need four documents, two of which would only contain one entry.  
Doable, yes.  But a little ugly.

If, on the other hand, a feed document is a sliding window into the 
historical states on entries (and thus, must allow multiple instances 
of particular entries), and if we don't want to archive the state of 
the feed, then we don't need a separate archive document type.  The 
latter seems likely to be supported by the WG, but the former does not. 
 I'd rather have an archive document type, and not repeat entries in 
normal feeds.



RE: PaceArchiveDocument posted

2005-02-07 Thread Bob Wyman

Antone Roundy wrote:
   entry
   id revision=3foo:bar/a/id
   ...
   /entry
 ...where @revision is a number whose only requirement is that the 
 number for a later revision be greater than the number for an
 earlier revision, but skipping numbers is allowed.
Providing an explicit revision number exclusively in atom:archives
has both advantages and costs.
If we assume that revision numbers start at 0 or 1 and increase
monotonically, then revision numbers gets us:
1. The ability to name or explicitly identify different versions of
an entry.
2. The ability to determine the order in which entries were written
-- independent of document order.
3. The ability to detect missing entry versions.
The cost of the three benefits above is, of course, the increased
complexity that comes from needing to maintain the version number associated
with an entry. Given that revision is an attribute which is not to be
stored in a normal feed document, this means that the feed document itself
cannot be used as the primary entry storage mechanism -- as is the case in
some systems today. In order to maintain revision numbers, a site that
provided an archive would have to have storage/memory external to the feed
document. The feed document could not be considered a complete
representation of even the current the state of the feed since part of the
state of the feed (the revision numbers of the current entries) would be
stored externally to the feed.

The first two benefits of version numbers can be had without a
requirement for maintaining any state if we make the version number a
DateTime. The requirement for saving state external to the feed document
could be removed by simply permitting the revision number to appear in the
feed document.
Is the third benefit -- detection of missing entries -- worth the
cost of requiring that state be maintained? Is it worth it in light of the
fact that a stateless alternative exists that provides all the other
benefits?
Is a revision attribute such a bad thing that it is really
necessary to increase the complexity of the system by requiring that it be
stored and maintained external to the feed document itself? Wouldn't it be
easier to just allow sites that archive to include the revision number in
their feed documents?
Given the two arguments above, it would seem that atom:modified
(must be updated on the change of any byte in an entry) would provide all of
the benefits that appear to be desired with the exception of missing entry
detection. 
Of course, if we went a step further and said that the unique
identifier for an entry was the concatenation of atom:id + (atom:revision OR
atom:modified), then we would no longer require the archive document type at
all...
But, I won't go there... 

bob wyman




Re: PaceArchiveDocument posted

2005-02-07 Thread James M Snell
Hmm... ok, at this point we have a point of disagreement.  I see 
archiving individual entries as being more important (or at least 
equally important) as archiving feeds.

Example: my weblog is a collection of entries, not a collection of 
feeds.  The feed published by my weblog is just a snapshot of a given 
point in time designed to allow others to read my entries without 
visiting my site.  When I archive, what I want to archive are the 
entries, not the feed.  archivefeed /feed //archive  does not 
make any sense to me.  archiveentry /entry //archive does. 
(ignore the angle brackets for now, I'm not trying to promote the idea 
of the archive element, I'm just illustrating my point).

Now, if I had my way, I would *probably* spec this out as:
* Archives work fundamentally on the entry level.
* An archived entry consists of all versions of the entry.
* Feeds are only archived as they relate to archived entries. For 
example, if a given entry has an associated comments feed, or some form 
of nested discussion feed, etc.  Such feeds are logically considered 
part of the metadata of the entry.

- James M Snell
Robert Sayre wrote:
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
We have feed documents. A series of feed documents makes an archive. I 
don't see why we need atom:archive after all.

Robert Sayre




Re: PaceArchiveDocument posted

2005-02-07 Thread Robert Sayre
James M Snell wrote:
+1.  We need to at least discuss the model a bit more before agreeing to
a syntax.  As with all things, there are many different ways we can do
this -- a new top level elements, the @profile attribute Mark and I have
been pitching, etc -- but unless we identify the general requirements
and a general model that we're shooting for, whatever we scrap together
here at the last minute is not going to be completely adequate.
The word archive shouldn't have been in the charter. Since no one even 
bothered to define the term over the past 8 months, I will do it now.

Archiving -- It must be possible to serialize a complete collection of 
entries using the Atom Format.

Robert Sayre


Re: AtomPubIssuesList for 2005/02/07

2005-02-07 Thread Paul Hoffman
Thanks, Sam.
Everyone: as Tim and I said last week, this is the last set of Paces 
we are considering for inclusion in the format document. If it's not 
on this list, it isn't considered unless you can show that there is a 
dire technical or security flaw in the document.

Please comment on each Pace separately. Even if you sent in a +1, 0, 
or -1 previously on a particular Pace, send it in again. Hopefully, 
add a short or long comment on why you feel it should or should not 
be considered part of the Atom core. Aggregated lists are cute, but 
greatly hurt the ability to hold a conversation.

Some of the Paces in this last round cover interesting and useful 
topics. Note, however, that interesting and useful does not mean 
core to Atom. We don't/can't have a strict definition of what is core 
to the protocol, but after over a year, many of us have a good 
feeling for that.

And, let's remember to have useful Subject: lines, OK?  If a thread 
changes direction, please change the subject line. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
Collecting a bunch of recent discussion into one document, how about 
these for a set of terms and their meanings:

* Entry: An abstract term describing a unit of content and metadata 
associated with it.
* Entry Representation: A representation of a particular state of a 
particular entry.
* Entry Document: A document, whose document element is entry, which 
contains a single Entry Representation.
* Feed: An abstract term describing a stream of Entry Representations.
* Feed Document: No such thing--replaced by Collection Documents and 
Archive Documents.
* Collection: Entry Representations of the current states of the 
Entries from a Feed.
* Collection Document: A document, whose document element is 
collection, which contains a Collection or a portion of a Collection.
* Archive: Entry Representations of the historical states of the 
Entries from a Feed.
* Archive Document: A document, whose document element is archive, 
which contains an Archive or a portion of an Archive.  Archive 
documents may contain multiple Entry Representations of the same Entry.

Publishers may choose to publish only Collection Documents, only 
Archive Documents, only Entry Documents, or any combination of these.  
So, for example, a publisher who does not track the historical states 
of their Entries might publish only a Collection Document.  A publisher 
who DOES track the historical states of their Entries might publish 
only an Archive Document, or both Collection and Archive Documents, or 
only a Collection Document.

Processing an Archive Document would be slightly more complicated than 
processing a Collection Document for clients that don't track the 
history of a Feed--for example, scripts that simply display the current 
contents of a Document on a website, because they might need to choose 
one from among multiple Entry Representations of the same Entry for 
display or other processing.

On Monday, February 7, 2005, at 10:13  AM, James M Snell wrote:
+1.  We need to at least discuss the model a bit more before agreeing 
to
a syntax.  As with all things, there are many different ways we can do
this -- a new top level elements, the @profile attribute Mark and I 
have
been pitching, etc -- but unless we identify the general requirements
and a general model that we're shooting for, whatever we scrap together
here at the last minute is not going to be completely adequate.

- James M Snell
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
So, it is not possible for the current doc to fulfill the charter, and
this document is not ready for last call.
wunder
--On February 6, 2005 2:00:20 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote:
-1.
	The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise 
to try to
rush through something this major at the last moment before a 
pending Last
Call.

bob wyman

--
Walter Underwood
Principal Architect, Verity




PaceArchiveDocument

2005-02-07 Thread Paul Hoffman
-1. Not core. The current text has a simple way of creating archives, 
and extensions can be used to create more specialized archive formats.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceJoinSectionSixAndTen

2005-02-07 Thread Paul Hoffman
At 5:09 PM + 2/7/05, Bill de hÓra wrote:
Paul Hoffman wrote:
-1. IETF documents have to have a Security Considerations section 
that describes general security issues. In no cases that I know of 
do they contain protocol specification. See RFC 3552 for more info.
Is that -1 to the proposed title or -1 to having one section?
The latter. In IETF documents, there should be a section that tells 
you how to do security, and another section that shows the bigger 
picture about security (such as known threats, other interesting 
security work, and so on).

--Paul Hoffman, Director
--Internet Mail Consortium


PaceEntryOrder

2005-02-07 Thread Paul Hoffman
+1. It is a simple clarification that shows the intention without 
restricting anyone.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceArchiveDocument posted

2005-02-07 Thread James M Snell
Yuck. I don't like the granularity of that at all.  I can see checking 
in individual entries, but not a single feed with every entry. What if 
I'm just changing the value of a single title attribute? Should I have 
to regenerate the entire feed and check in the entire feed just to 
update the archive for one minor edit?  That would be kind of like 
taking all the source code for a given project, zipping it up into a 
single zip file and checking that into subversion.  Sure, it would work, 
but dang that's nasty (not that it's not being done).  Better to archive 
individual entries.  Sure, archiving of feeds can be done also, but 
archiving feeds is separate from archiving entries.  They are separate 
documents, treat them separately.

- James M Snell
Robert Sayre wrote:
Antone Roundy wrote:

If Atom Documents are not allowed to contain multiple instances of a 
particular resource, then archiving the states of an entry would 
require the feed to be split into more, smaller feed documents any 
time an entry is edited without many other entries being published in 
between edits.  For example, if you published an entry, decided to 
revise a paragraph and published again, found a misspelling and 
published again, and then fixed and published another misspelling, 
you'd need four documents, two of which would only contain one entry.  
Doable, yes.  But a little ugly.

No, I'm saying I would regenerate a feed with every entry in it every 
time I make a change. Then, I would check it into Subversion.

Robert Sayre




Removing your old Paces from consideration

2005-02-07 Thread Paul Hoffman
Someone pointed out that some of the Paces in the current rotation 
have been informally withdrawn by their authors. Good point. If you 
have such a Pace, please send mail to the list saying so, and Sam can 
remove it from the wiki.

--Paul Hoffman, Director
--Internet Mail Consortium


PaceClarifyDateUpdated

2005-02-07 Thread Robert Sayre
-1. Doesn't make sense or add value to the document.
Robert Sayre


Re: PaceEntryOrder

2005-02-07 Thread Robert Sayre
Paul Hoffman wrote:
+1. It is a simple clarification that shows the intention without 
restricting anyone.
+1. Agree in full.
Robert Sayre


Re: PaceArchiveDocument

2005-02-07 Thread Robert Sayre
Paul Hoffman wrote:
-1. Not core. The current text has a simple way of creating archives, 
and extensions can be used to create more specialized archive formats.

-1 to the Pace. Agree in full.
Robert Sayre


Re: PaceJoinSectionSixAndTen

2005-02-07 Thread Bill de hÓra
Paul Hoffman wrote:
The latter. In IETF documents, there should be a section that tells you 
how to do security, and another section that shows the bigger picture 
about security (such as known threats, other interesting security work, 
and so on).
I can tell this isn't worth arguing about :) I've withdrawn the pace and 
notified Sam.

cheers
Bill


Re: AtomPubIssuesList for 2005/02/07

2005-02-07 Thread Bill de hÓra
Sam Ruby wrote:
Like I did last time, I am simply scheduling all the open format items 
in the hopes that we can drive this list to zero.


PaceJoinSectionSixAndTen
Hi Sam,
I'd like to withdraw this one from consideration, it doesn't fit with 
the IETF way (...mumbles darkly about the ietf way...).

cheers
Bill


PaceDatesXSD

2005-02-07 Thread Robert Sayre
+1. Our AD has told us how to write this section, so the Pace just adds 
the regex, which I'm in favor of. Sam's suggestion at the end could 
easily be accomodated with a sentence saying As a result, the date 
values are valid according to  [RFC3339], [XML-SCHEMA], and [w3cdtf].

Robert Sayre


Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 10:26  AM, Bob Wyman wrote:
Antone Roundy wrote:
entry
id revision=3foo:bar/a/id
...
/entry
...where @revision is a number whose only requirement is that the
number for a later revision be greater than the number for an
earlier revision, but skipping numbers is allowed.
	Providing an explicit revision number exclusively in atom:archives
has both advantages and costs.
	If we assume that revision numbers start at 0 or 1 and increase
monotonically, then revision numbers gets us:
	1. The ability to name or explicitly identify different versions of
an entry.
	2. The ability to determine the order in which entries were written
-- independent of document order.
	3. The ability to detect missing entry versions.
	The cost of the three benefits above is, of course, the increased
complexity that comes from needing to maintain the version number 
associated
with an entry.
Only if the version number for a particular Entry Representation needs 
to remain constant.  I'd be fine with it either way--simplicity and 
only #2 (and limited #1--you can do it within the context of a 
particular instance of the archive, but can't be sure it won't change 
when you download the archive again) vs. storing the version number and 
getting all 3.

The first two benefits of version numbers can be had without a
requirement for maintaining any state if we make the version number a
DateTime.
Of course, you'd have to store the DateTime.  It's more likely that 
people are already doing that, so for those that are, this would be 
preferable.  Those who aren't are likely not storing the historical 
states of the entry at all.

	Is a revision attribute such a bad thing that it is really
necessary to increase the complexity of the system by requiring that 
it be
stored and maintained external to the feed document itself? Wouldn't 
it be
easier to just allow sites that archive to include the revision number 
in
their feed documents?
I'd have no problem with allowing that.
	Given the two arguments above, it would seem that atom:modified
(must be updated on the change of any byte in an entry) would provide 
all of
the benefits that appear to be desired with the exception of missing 
entry
detection.
True.  Rather than going back into the whole discussion of dates, we 
could let people who want to get benefits #1 and #2 can store 
dc:modified (since atom:modified) doesn't currently exist, and those 
who don't do that can either invent their own extension like @revision. 
 So archive documents as defined in Atom wouldn't include either, and 
the market would show us which would prevail.

I'm feeling a little apathetic about exactly how we do it at the moment.


PaceSecuritySection

2005-02-07 Thread Robert Sayre
+1. Says all that we need to without getting into HTML too deeply.
Robert Sayre


Re: PaceCaching posted

2005-02-07 Thread Walter Underwood
This is not restricted to HTTP. It uses HTTP's cache age algorithms,
because they are very carefully designed and have proven effective.
But it can be used for any local copy in an Atom client.
wunder
--On Monday, February 07, 2005 10:08:48 AM -0800 Paul Hoffman [EMAIL 
PROTECTED] wrote:
At 9:38 AM -0800 2/7/05, Walter Underwood wrote:
I was holding this back as out of scope and too close to the deadline,
but now that we are talking about sliding windows and delayed, cached
state, it is quite relevant.
Sorry, this is too late for consideration for the Atom core. Even if you 
had turned it in on time, I would give it a -1 for not being essential to the 
core for the Atom format. Atom will be distributed over many protocols, HTTP 
being one of them. Having said that, I think this would be an excellent 
extension, one that might keep the folks who don't understand HTTP scalability 
but feel free to talk about it anyway at bay.
--Paul Hoffman, Director
--Internet Mail Consortium

--
Walter Underwood
Principal Architect
Verity Ultraseek


PaceMultipleImages

2005-02-07 Thread Robert Sayre
Some feel that since the atom:image could contain text, multiple 
instances ought to be allowed for to support multilanguage.

These people are wrong. -1 to the Pace.
Robert Sayre


Re: PaceArchiveDocument

2005-02-07 Thread John Panzer
-1 to the Pace.  The current syntax sufficiently meets the 'support for 
archives' charter, and extensions are possible.
-John



PaceNoFeedState

2005-02-07 Thread Antone Roundy
+1.  There are too many little details that we haven't worked out in 
exactly how to reconstruct the state of a feed to try to define it now.



RE: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Bob Wyman

Antone Roundy wrote:
 [polling] would result in bandwidth usage being spread over time 
 better than push, assuming push servers push new entries out to 
 everyone as quickly as possible after they're published.
At PubSub, we operate both a push and a pull service. We know from
experience that the push service results in drastically less bandwidth per
user then the polling service does. This is not based on theory -- rather
the statement is based on real empirical evidence of running both services
side by side. The bandwidth savings of the push service comes from the fact
that we don't have to handle the poll requests themselves and we never
publish the same item twice to a single subscriber as is inevitably the case
with a multi-entry polled RSS/Atom file.
In order to demonstrate polling at its most efficient, I defined and
convinced a number of folk to implement RFC3229+feed. This HTTP extension
eliminates the problem with sending multiple copies of messages to people
and the resulting drop in bandwidth requirements for those who poll and use
RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still
consumes more bandwidth then the push service. Once again, this ain't
theory, it is experience.

 I've lost track of what aspect of Atom's architecture you 
 are saying is bound to polling at the expense of push.
There are several Feed-oriented or polling oriented discussions
going on:
1. The requirement that feeds not be permitted to contain multiple
entries that have the same atom:id. This requirement prevents push based
system from using feeds as logs or histories of messages sent. For
instance, at PubSub, the Atom file which is associated with every
subscription contains a stream of entries that are the entries that either
were or would have been sent to the client if it had been connected. The
first thing a client does on starting up is to read the Atom file in order
to synchronize state with the server. Thus, the feed is actually just a
trace of the messages sent. This probably sounds weird if you're
feed-focused; however, it makes perfect sense if you are pushing entries.
2. Significance of the order of entries in feeds. A push-fed client
only sees feeds in edge cases (like the PubSub synchronization usage
discussed above). Because a push-fed client receives a stream of entries --
not feeds, it can only see chronological order unless order is encoded
within the entry itself. Any requirement that document order is significant
(and some are still suggesting it is) means that a push-based system must
push entire feeds rather then individual entries. The bandwidth costs of
doing so would be completely unacceptable. (Things like ordered lists should
be handled by having entries that contain ordered lists. Exploiting the
anecdotal attributes of the atom:feed document and the practices of current
aggregators is NOT reasonable.)
3. The absence of a revision id or atom:modified. The feed-ists
don't see the need for revision numbers in part because they are focused on
feeds rather than entries. If you live in the world of entries -- as a push
system does -- then the need to distinguish multiple versions of the same
entry becomes much, much more important.

I have an additional set of concerns that are based on our
experience as generators of aggregate feeds. The problem is that we are at
the mercy of the creators of feeds... The rules say, as they should, that
we're not supposed to change the atom:id of something that we extract from a
feed. Thus, when we generate results, we should use the atom:id's that we
found in the source entries. However, if someone fails to create really
unique atom:id's, we are left wondering what to do... We aren't supposed to
generate a feed with repeat atom:id's according to the spec, however, our
users will want to see all entries that match their search terms. We have to
either conform to the Atom spec by dropping one of the Entries from the
results -- and thus serve our users less well, or, we have to generate new
atom:id's in order to serve our users but violate the specification. In
other words, we can't win.
Similarly, the prohibition against multiple instances of an atom:id
means that we can't implement a show me all versions feature using Atom as
the packaging format for the results. (No, we're not planning to do this.
But, it would be good to be able to do it.)

bob wyman

[1] http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html




Re: PaceEntryOrder

2005-02-07 Thread Walter Underwood

--On February 7, 2005 1:06:49 PM -0500 Robert Sayre [EMAIL PROTECTED] wrote:
 Paul Hoffman wrote:
 
 +1. It is a simple clarification that shows the intention without 
 restricting anyone.
 
 +1. Agree in full.

-1. I don't see the benefit. Clients MAY re-order them, but that
doesn't mean they MUST ignore the order. The publisher may prefer
an order which cannot be expressed in the attributes. The Macintouch
and BBC New feeds cited before are good examples.

wunder
--
Walter Underwood
Principal Architect, Verity



PaceIconAndImage

2005-02-07 Thread Antone Roundy
+1 if image is changed to logo or, even better, if image is 
allowed in entry.  I don't care whether icon is allowed in entry, 
though I see no reason not to allow it.



PaceLinkEnclosure

2005-02-07 Thread Antone Roundy
+1, and +1 to calling it attachment instead of enclosure.


PaceFormatSecurity

2005-02-07 Thread Antone Roundy
+1.  But let's add something to the effect of consumers MAY ignore 
unrecognized CSS/(X)HTML and any CSS/(X)HTML that they are not 
confident will not result in security problems.



PaceSecuritySection

2005-02-07 Thread Antone Roundy
-1: Not enough information.  We may not need all the detail of 
PaceFormatSecurity, but PaceSecuritySection goes too far the other way.



Re: PaceSecuritySection

2005-02-07 Thread Paul Hoffman
At 1:17 PM -0500 2/7/05, Robert Sayre wrote:
+1. Says all that we need to without getting into HTML too deeply.
Wearing my IETF hat, +1. Also, be aware that there is probably a 50% 
chance that we will get additions to this section from the IETF last 
call or from the IESG.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceFormatSecurity

2005-02-07 Thread Paul Hoffman
-1. If the current security documents that cover the material are 
insufficient, they should be fixed, and not have it listed in our 
document. We should only point to where generic information can be 
found and list things that are Atom-specific.

--Paul Hoffman, Director
--Internet Mail Consortium


PaceXhtmlNamespaceDiv

2005-02-07 Thread Henri Sivonen
On Feb 7, 2005, at 19:50, Paul Hoffman wrote:
Even if you sent in a +1, 0, or -1 previously on a particular Pace, 
send it in again. Hopefully, add a short or long comment on why you 
feel it should or should not be considered part of the Atom core.
-1 on PaceXhtmlNamespaceDiv
The div is an additional container inside the Text construct container. 
The main purpose of the div is to save one for loop in a 
document-tree/pull-based client or, alternatively, to give a false 
sense of correctness in tag soup concatenation-based clients. IMO, 
neither rationale warrants a meaningless element inside a Text 
construct.

(Noting that the Pace was retracted by the original author.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceEntryOrder

2005-02-07 Thread Sam Ruby
Walter Underwood wrote:
--On February 7, 2005 1:06:49 PM -0500 Robert Sayre [EMAIL PROTECTED] wrote:
Paul Hoffman wrote:
+1. It is a simple clarification that shows the intention without 
restricting anyone.
+1. Agree in full.
-1. I don't see the benefit. Clients MAY re-order them, but that
doesn't mean they MUST ignore the order. The publisher may prefer
an order which cannot be expressed in the attributes. The Macintouch
and BBC New feeds cited before are good examples.
I'm +1 on the Pace as written.  I'd be equally +1 on a modifed Pace 
where SHOULD NOT was used in place of MUST NOT.

- Sam Ruby


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Sam Ruby
Henri Sivonen wrote:
On Feb 7, 2005, at 19:50, Paul Hoffman wrote:
Even if you sent in a +1, 0, or -1 previously on a particular Pace, 
send it in again. Hopefully, add a short or long comment on why you 
feel it should or should not be considered part of the Atom core.
-1 on PaceXhtmlNamespaceDiv
The div is an additional container inside the Text construct container. 
The main purpose of the div is to save one for loop in a 
document-tree/pull-based client or, alternatively, to give a false sense 
of correctness in tag soup concatenation-based clients. IMO, neither 
rationale warrants a meaningless element inside a Text construct.

(Noting that the Pace was retracted by the original author.)
It was retracted due to a perceived lack of interest - at that point it 
was a two party dialog between yourself and that author.

Since then a number of folks (myself included) expressed support for 
this Pace, I reopened it with an email to the list, and I will now 
reiterate my support now with a +1.

There are a number of issues that this resolves, such as whether the div 
element itself is to be considered part of the content in protocol POST 
methods.  If they are not, you will tend over time to see multiple such 
wrappings.

-Sam Ruby



Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 12:00  PM, Bob Wyman wrote:
	In order to demonstrate polling at its most efficient, I defined and
convinced a number of folk to implement RFC3229+feed. This HTTP 
extension
eliminates the problem with sending multiple copies of messages to 
people
and the resulting drop in bandwidth requirements for those who poll 
and use
RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still
consumes more bandwidth then the push service. Once again, this ain't
theory, it is experience.
You are of course the one in a position to know about this.  I'm 
curious though--do you have figures on how much push reduced bandwidth 
use vs. RFC3229+feed?  My guess would be that the difference wouldn't 
be as dramatic as between feed and RFC3229+feed, but I recognize that I 
may be wrong.  That guess is what I was expressing.

I've lost track of what aspect of Atom's architecture you
are saying is bound to polling at the expense of push.
	There are several Feed-oriented or polling oriented discussions
going on:
	1. The requirement that feeds not be permitted to contain multiple
entries that have the same atom:id. This requirement prevents push 
based
system from using feeds as logs or histories of messages sent. For
instance, at PubSub, the Atom file which is associated with every
subscription contains a stream of entries that are the entries that 
either
were or would have been sent to the client if it had been connected. 
The
first thing a client does on starting up is to read the Atom file in 
order
to synchronize state with the server. Thus, the feed is actually just a
trace of the messages sent. This probably sounds weird if you're
feed-focused; however, it makes perfect sense if you are pushing 
entries.
It doesn't sound particularly weird, though I don't understand why the 
typical client would feel the need to see obsolete representations of 
entries that had been changed more than once while they were offline.  
I fully agree that we should not lock out the option of including 
multiple instances of an entry in some kind of Atom Document.  But I 
also don't think that we should require all Atom Documents (other than 
Entry Documents) to do so.  In other words, I don't think this is an 
either-or question--I think both should be possible.

	2. Significance of the order of entries in feeds. A push-fed client
only sees feeds in edge cases (like the PubSub synchronization usage
discussed above). Because a push-fed client receives a stream of 
entries --
not feeds, it can only see chronological order unless order is encoded
within the entry itself. Any requirement that document order is 
significant
(and some are still suggesting it is) means that a push-based system 
must
push entire feeds rather then individual entries. The bandwidth costs 
of
doing so would be completely unacceptable.
Agreed.
	3. The absence of a revision id or atom:modified. The feed-ists
don't see the need for revision numbers in part because they are 
focused on
feeds rather than entries. If you live in the world of entries -- as a 
push
system does -- then the need to distinguish multiple versions of the 
same
entry becomes much, much more important.
Makes sense.  I personally have come to like the idea of using 
dc:modified rather than defining atom:modified.  (I am a proponent of 
atom:updated because there is no Dublin Core equivalent for it).



Re: PaceIconAndImage

2005-02-07 Thread Robert Sayre
-1. image should be exactly as it is in RSS, except with the 
recommendation that it should be 1:1, instead of size recomendations. 
There's also no reason to limit it to atom:head.

icon is silly.
link rel=icon should usher in the brave new world of HTML relations 
leaking into the Atom space. Alright.

Robert Sayre


Re: PaceEntryOrder

2005-02-07 Thread John Panzer
+1.  Low cost, good benefits for interoperability.


PaceXhtmlNamespaceDiv

2005-02-07 Thread Antone Roundy
+1, but I wouldn't object to a variant that required either the DIV 
with a namespace declaration OR for the namespace to be declared in 
content or before content.  Examples of what I'd think was 
acceptable:

feed ... xmlns:xhtml=... /
...
contentThis is xhtml:bbold/xhtml:b/content
OR
content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content
OR
contentdiv xmlns=... /This is bbold/b/content
Here's what I think is just plain ugly and shouldn't be allowed:
contentThis is b xmlns=... bold/b/content
OR
contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content


Re: PaceEntryOrder

2005-02-07 Thread Graham
+1, with the proviso that I think the first sentence is entirely 
meaningless.

Graham


Re: PaceFormatSecurity

2005-02-07 Thread Robert Sayre
Sam Ruby wrote:
It seems to me that we have an obligation to either (1) disallow HTML, 
or (2) mitigate allowing HTML by providing a security section such as 
this one.

If (2) can be solved by reference, then that clearly would be preferred. 
 But to date, no such reference has been found.
So, engaging in bad specification practice[0] is the answer? HTML 
security is a problem for the W3C and/or an HTML-WG. Existing RFCs 
constitute the IETF's definition of adequate security coverage for HTML. 
 If we want to change the status quo in our document, we need to say 
that we're updating those RFCs at the top of our document.

Robert Sayre
[0] http://www.imc.org/atom-syntax/mail-archive/msg12625.html


Re: PaceFormatSecurity

2005-02-07 Thread Graham
-1, agree with Robert.
Graham
On 7 Feb 2005, at 6:35 pm, Robert Sayre wrote:
-1. Covers HTML in too much detail, though it's still inadequate 
coverage. This is isn't our problem. I blame the W3C :)

Robert Sayre



Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Graham
On 7 Feb 2005, at 7:38 pm, Sam Ruby wrote:
Since then a number of folks (myself included) expressed support for 
this Pace, I reopened it with an email to the list, and I will now 
reiterate my support now with a +1.

There are a number of issues that this resolves, such as whether the 
div element itself is to be considered part of the content in protocol 
POST methods.  If they are not, you will tend over time to see 
multiple such wrappings.
+1, and not just because it will make my life easier.
Graham


PaceCommentFeeds

2005-02-07 Thread Antone Roundy
+1: if not the whole Pace, then at least link/@rel=comments.


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Anne van Kesteren
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.

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


PaceEntriesElement

2005-02-07 Thread Antone Roundy
-1: recursion is too complex and bulky.


PaceFeedRecursive

2005-02-07 Thread Antone Roundy
-1: recursion is too complex and bulky.  But we could (should?) specify 
lack of recursion in terms of particular types of Atom Documents or 
particular profiles, leaving the door open for extensions to define 
document types that allow recursion.



Re: PaceArchiveDocument posted

2005-02-07 Thread Henry Story
I think that the complexity that this proposal is proof of its failure.
If you look at a Feed document as simply a sliding window view into
the historical state of entries instead a sliding window view into the
current state of entries (though as I have shown these can overlap),`
then you have your archive document already.
HELLO GUYS/GALS YOU ARE THERE AT THE FINISH LINE. IT ALL WORKS!
One of the arguments against the sliding window view in the historical
state of entries is that it was too complicated. But clearly not going
that way is making things WAY MORE COMPLICATED.
So before proceeding any further it may be worth now comparing the
complexity of both proposals in detail. My guess is that the historical 
one is just a little surprising, but that is all.

Henry Story


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Henri Sivonen
On Feb 7, 2005, at 21:52, Antone Roundy wrote:
+1, but I wouldn't object to a variant that required either the DIV 
with a namespace declaration OR for the namespace to be declared in 
content or before content.  Examples of what I'd think was 
acceptable:

feed ... xmlns:xhtml=... /
...
contentThis is xhtml:bbold/xhtml:b/content
This is against the Pace. Are you really supporting the pace?
OR
content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content
This is against the Pace, too.
OR
contentdiv xmlns=... /This is bbold/b/content
This one is against the pace as well. Also, the 'b' element would be in 
the same namespace as 'content', which seems wrong.

Here's what I think is just plain ugly and shouldn't be allowed:
contentThis is b xmlns=... bold/b/content
IMO, that should be allowed. Atom has no business in restricting the 
syntactic sugar provided by Namespaces in XML.

OR
contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content
IMO, this on should be allowed on the same grounds.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


PaceRemoveVersionAttr

2005-02-07 Thread Antone Roundy
+1.  I'd like to see language specifying how the namespace can be used 
to determine compatibility between revisions of the specification--ie. 
any app that can handle one version of Atom can handle any version 
sharing the same namespace, and any feed that's valid under any version 
of Atom is valid under any version sharing the same namespace.



Re: PaceIconAndImage

2005-02-07 Thread Graham
+1, agree with renaming image to logo. Disagree with allowing either in 
entry, since their are already one million ways to do that (HTML, 
[EMAIL PROTECTED], etc).

Graham
On 7 Feb 2005, at 7:08 pm, Antone Roundy wrote:
+1 if image is changed to logo or, even better, if image is 
allowed in entry.  I don't care whether icon is allowed in entry, 
though I see no reason not to allow it.




Re: PaceArchiveDocument posted

2005-02-07 Thread Henry Story
On 7 Feb 2005, at 18:29, Antone Roundy wrote:
The latter seems likely to be supported by the WG, but the former does 
not.  I'd rather have an archive document type, and not repeat entries 
in normal feeds.
I don't think the historical sliding window view forces you at all
to duplicate the entries in your feed. The spec allows you to remove 
all the old versions if you wish. After all the Present time, is just
one element in the sequence of history.

People who only want to live in the present don't negate history. They
just don't remember it.
Henry Story


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread James M Snell
Ok, now that I'm thinking about this more, I'm changing my initial +0 to 
+1.  This just makes sense.  There does need to be a container for the 
XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.

- James M Snell
Antone Roundy wrote:
+1, but I wouldn't object to a variant that required either the DIV with 
a namespace declaration OR for the namespace to be declared in content 
or before content.  Examples of what I'd think was acceptable:

feed ... xmlns:xhtml=... /
...
contentThis is xhtml:bbold/xhtml:b/content
OR
content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content
OR
contentdiv xmlns=... /This is bbold/b/content
Here's what I think is just plain ugly and shouldn't be allowed:
contentThis is b xmlns=... bold/b/content
OR
contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content




Re: PaceFeedRecursive

2005-02-07 Thread Henry Story

On 19 Jan 2005, at 10:38, Henry Story wrote:
I think the easiest way to get what you want is a 2 step procedure:
  1. Merge the Head with the Entry constructs. They are not different 
enough
for the difference to be important.
  2. Make a Feed a subclass of Entry, with the extra property of being 
able
 to point to a Entry (Since a Feed is a Entry, it also points to 
other Feeds)

I am  +1 on such a refactoring. Nothing will be lost doing this, and a 
lot gained
in simplicity.

Henry
I now no longer believe 2. Is needed.
1 would be quite neat though.
Henry


Re: PaceEntryOrder

2005-02-07 Thread Paul Hoffman
At 11:07 AM -0800 2/7/05, Walter Underwood wrote:
-1. I don't see the benefit. Clients MAY re-order them, but that
doesn't mean they MUST ignore the order. The publisher may prefer
an order which cannot be expressed in the attributes. The Macintouch
and BBC New feeds cited before are good examples.
I'm very confused. Clients that show the entries of those feeds in 
the received order are perfectly acceptable according to the wording 
of this Pace.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceArchiveDocument

2005-02-07 Thread Henri Sivonen
On Feb 7, 2005, at 20:04, Robert Sayre wrote:
Paul Hoffman wrote:
-1. Not core. The current text has a simple way of creating archives, 
and extensions can be used to create more specialized archive 
formats.
-1 to the Pace. Agree in full.
-1 to the Pace. Me three.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Anne van Kesteren
James M Snell wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 to 
+1.  This just makes sense.  There does need to be a container for the 
XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.
I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for string based generators be to apply it on 
the DIV element?

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


Re: PaceEntriesElement

2005-02-07 Thread Henry Story
-1 I agree. Recursion can be placed in the model. It does not
need to be in the syntax. In any case this is too big a change
too late in the game.
Henry
On 7 Feb 2005, at 21:08, Antone Roundy wrote:
-1: recursion is too complex and bulky.



Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread James M Snell
Yes, sorry I wasn't clear.  Not *only* on ancestor elements. any of the 
following cases should be allowed.

feed
  entry
content
  xhtml:div xmlns:xhtml=... /
/content
  /entry
/feed
feed
  entry
content xmlns:xhtml=...
  xhtml:div /
/content
  /entry
/feed
feed
  entry xmlns:xhtml=...
content
  xhtml:div /
/content
  /entry
/feed
feed xmlns:xhtml=...
  entry
content
  xhtml:div /
/content
  /entry
/feed
- James M Snell
Anne van Kesteren wrote:
James M Snell wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 
to +1.  This just makes sense.  There does need to be a container for 
the XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.

I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for string based generators be to apply it on 
the DIV element?





Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread James M Snell
Nah, I don't buy it.  XHTML is just a special case of an XML content and 
if we were embedding some XML data (say an atom:feed) it wouldn't make 
any sense (under the assumption that the content / element is top 
level container) for us to do:

content type=application/atom+xml
  head
...
  /head
  entry
...
  /entry
/content
In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.

- James M Snell
Henri Sivonen wrote:
On Feb 7, 2005, at 22:18, James M Snell wrote:
There does need to be a container for the XHTML and div is a solid, 
logical choice.

The container is the Atom Text construct itself!



Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Henri Sivonen
For the record, the additional loop that the div would save in a 
DOM-based client is not that hard:

copyLangAndBase(atomTextCostruct, targetDivInTemplate);
for (Node n = atomTextCostruct.getFirstChild(); n != null; n = 
n.getNextSibling()) {
	targetDivInTemplate.appendChild(templateXhtmlDocument.importNode(n, 
true));
}

Is that too much to ask from clients?
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Anne van Kesteren
James M Snell wrote:
Nah, I don't buy it.  XHTML is just a special case of an XML content and 
if we were embedding some XML data (say an atom:feed) it wouldn't make 
any sense (under the assumption that the content / element is top 
level container) for us to do:

content type=application/atom+xml
  head
...
  /head
  entry
...
  /entry
/content
I do not follow this example.

In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.
So you want a DIV as wrapper element for TITLE and similar elements as well?
--
 Anne van Kesteren
 http://annevankesteren.nl/


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Sam Ruby
Anne van Kesteren wrote:
James M Snell wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 
to +1.  This just makes sense.  There does need to be a container for 
the XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.
I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for string based generators be to apply it on 
the DIV element?
I'm confused.  If you are opposed to this pace, then what div element?
It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the div element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?

- Sam Ruby


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Anne van Kesteren
Sam Ruby wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 
to +1.  This just makes sense.  There does need to be a container for 
the XHTML and div is a solid, logical choice.  I don't think it 
should matter where the xmlns is declared... any ancestor element 
will do.
I'm still -1. But I was wondering, why only ancestor elements? 
Wouldn't the most logical thing for string based generators be to 
apply it on the DIV element?
I'm confused.  If you are opposed to this pace, then what div element?
That was a question in reply to what James wrote. It appeared to be an 
error.


It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the div element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?
If the page is adopted, which I hope not, it MUST NOT be part of the 
content. If the page is not adopted it MUST be part of the content.

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


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread James M Snell
Anne van Kesteren wrote:
James M Snell wrote:
Nah, I don't buy it.  XHTML is just a special case of an XML content 
and if we were embedding some XML data (say an atom:feed) it wouldn't 
make any sense (under the assumption that the content / element is 
top level container) for us to do:

content type=application/atom+xml
  head
...
  /head
  entry
...
  /entry
/content

I do not follow this example.
The point is that content / should not be viewed as the root element 
for contained XML.  The XML content should be able to stand on it's own, 
indepedently of the content or text construct element as well-formed XML.


In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.

So you want a DIV as wrapper element for TITLE and similar elements as 
well?


For Text construct and Content, if XHTML is used, there should be a DIV. 
 If someone wants to use XHTML for title, then yes, they should use a 
DIV. Otherwise, they can use plain text.


- James M Snell


PaceProfileAttribute

2005-02-07 Thread Antone Roundy
-1: One profile (or maybe set of profiles) per document is better in my 
opinion.  If an aggregator aggregates entries with different profiles, 
it can either fix them up as needed to conform to a common profile, or 
if multiple profiles can be specified at the top level, declare the 
profiles for all of the entries in the document there.



Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Sam Ruby
Anne van Kesteren wrote:
Sam Ruby wrote:
Ok, now that I'm thinking about this more, I'm changing my initial 
+0 to +1.  This just makes sense.  There does need to be a container 
for the XHTML and div is a solid, logical choice.  I don't think it 
should matter where the xmlns is declared... any ancestor element 
will do.

I'm still -1. But I was wondering, why only ancestor elements? 
Wouldn't the most logical thing for string based generators be to 
apply it on the DIV element?
I'm confused.  If you are opposed to this pace, then what div element?
That was a question in reply to what James wrote. It appeared to be an 
error.

It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the div element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?
If the page is adopted, which I hope not, it MUST NOT be part of the 
content. If the page is not adopted it MUST be part of the content.
I can easily sit back and adopt a wait and see and I told you so 
attitude, but by now it should be obvious that I care too much about the 
success of this format and protocol to do that.

If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
  2) Tim (who uses string concatenation) will have to do more work.
  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
  3) More feeds will be invalid (content in atom namespace)
  4) More feeds will be incorrect (in the sense that Tim's feed does
 accurately reflect the content of his entries).
  5) For some combinations of clients and servers, entries produced
 via an HTTP POST will end up with multiple divs.
Meanwhile, now that the location where the namespace can be declared 
details have been removed from this pace, Henri can continue to do a 
DOM-to-DOM copy.

I stand by my original statements:
  There are cases where explicit is better than implicit.
  Given that common practice is to include this element, making it
  mandatory makes things clearer to both people who are producing
  consuming tools based on the spec, and people who are producing new
  feeds based on copy and paste.
- Sam Ruby


Re: PaceEntryOrder

2005-02-07 Thread Sam Ruby
David Powell wrote:
Monday, February 7, 2005, 7:23:15 PM, you wrote:
I'm +1 on the Pace as written.  I'd be equally +1 on a modifed Pace 
where SHOULD NOT was used in place of MUST NOT.
Sam, have you misread the Pace?  The only occurrence of MUST NOT is
in the Rationale, where it has been copied from Atom 0.3 as an
example.
The proposal is to add the following paragraph:
   This specification assigns no significance to the order of
   atom:entry elements within the feed. Processors MAY present entries
   in a different order to which they are appear in an Atom Feed
   Document.
Also, Walter's comment seems to suggest the same confusion:
-1. I don't see the benefit. Clients MAY re-order them, but that
doesn't mean they MUST ignore the order. The publisher may prefer an
order which cannot be expressed in the attributes. The Macintouch
and BBC New feeds cited before are good examples.
I'll try to be a bit more conservative with the PRE tags in future :)
Yes, I misread it.  To be clear:
1) I am +1 to the original wording that somehow got lost.
2) I am +1 to the proposed rewording.
Ultimately, the sentiment that I want conveyed is that publishers are 
not safe to assume that clients will read anything into the order.

- Sam Ruby


PaceAggregationInSeparateSpec

2005-02-07 Thread Antone Roundy
+1 if:
1) it means that head-in-entry is removed.
AND
2) profiles or some extension mechanism would enable people to do 
head-in-entry for those who want to use that method, but which I DON'T 
mean this:

entry
ext:head
ext:feed-title /
ext:feed-updated /
...
/ext:head
...
/entry
but this:
entry
ext:head
title /
updated /
...
/ext:head
...
/entry


Re: PaceEntryOrder

2005-02-07 Thread Walter Underwood
--On Monday, February 07, 2005 12:24:15 PM -0800 Paul Hoffman [EMAIL PROTECTED] wrote:
At 11:07 AM -0800 2/7/05, Walter Underwood wrote:
-1. I don't see the benefit. Clients MAY re-order them, but that
doesn't mean they MUST ignore the order. The publisher may prefer
an order which cannot be expressed in the attributes. The Macintouch
and BBC New feeds cited before are good examples.
I'm very confused. Clients that show the entries of those feeds in
the received order are perfectly acceptable according to the wording of this 
Pace.
Correct, clients may choose any order, including the original.
This is about the publisher's order preference. The Pace says that
the publisher cannot indicate a preferred order in the Atom format.
The order is not significant.
This is clearly counter to normal use, where the order does have
some meaning. The meaning varies by publisher, but it is usually
significant.
wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek


Re: PaceProfileAttribute

2005-02-07 Thread Antone Roundy
I'm in favor of profiles, just -1 to allowing @profile on sub-elements. 
 So I prefer PaceProfile to PaceProfileAttribute.

On Monday, February 7, 2005, at 02:17  PM, James M Snell wrote:
This is entirely possible also.  Just to be clear tho, you're not 
-1'ing the idea of profiles, just the allowing of the @profile 
attribute on sub-elements (e.g. entries contained in feeds) correct?  
This is an important distinction because I'm definitely not married to 
the syntax as presented but would definitely like to see us adopt the 
profile mechanism in general.

- James M Snell
Antone Roundy wrote:
-1: One profile (or maybe set of profiles) per document is better in 
my opinion.  If an aggregator aggregates entries with different 
profiles, it can either fix them up as needed to conform to a common 
profile, or if multiple profiles can be specified at the top level, 
declare the profiles for all of the entries in the document there.




Re: PaceProfile

2005-02-07 Thread James M Snell
The specification of multiple profiles is one of the differences between 
PaceProfile and PaceProfileAttribute.  Mark's original proposal does not 
allow for multiple profiles, mine does.

Mark's Proposal:
* @profile or modified @version on the document level
* one profile per document
* profile applies to the entire document
* a profile describes what metadata elements are required and 
cardinality thereof

My Proposal:
* @profile on the atom:feed / and atom:entry / levels (independent 
of document arrangement)
* multiple profiles per atom:feed / atom:entry /
* profile applies just to the atom:feed / or atom:entry / element 
upon which it appears.  it does not apply recursively down the structure.
* a profile describes what metadata elements are required and 
cardinality thereof
* profile is strictly informational and does not impose any operational 
requirements on the part of consumers/producers

Mine is admitedly more complex, but it also, in my opinion, provides 
greater flexibility.  Whether that greater flexibility is required is a 
separate question that is open for debate.

WRT multiple profiles, since all a profile is is a statement of which 
elements are required and the cardinality thereof, the union of the 
profile requirements is what is expected in the document.  For instance, 
if profileA requires foo / and profileB requires bar /, processors 
should expect foo / and bar /.  The only contention will be if 
profileA and profileB specify requirements for a different cardinality 
of some common element.  e.g. profileB requires no more than 1 foo / 
and profileA requires no fewer than 2 foo /.  If the element contains 
2 foo /, then the processor determines that the element is conformant 
with profileA, but not profileB.  It is up to the processor to figure 
out what to do in such cases. Alternatively, a rule can be specified 
that the profile with the highest cardinality for element foo / takes 
precedence.

For interoperability sake, the creation of profiles should have a 
somewhat high bar.  creating another profile that describes exactly 
what you're after should not be something done willy-nilly if you 
expect people to have a clue what they're producing/processing. 
Restricting profiles as we've done, composing multiple well-defined 
profiles on the fly will be more reliably interoperable than creating a 
brand new profile to fit some specific situation.

 Question: If head-in-entry were removed from the spec, could a profile
 indicate that entry could contain a head that specified the feed
 data relevant to the entry?  I'd be in favor of handling aggregation
 that way, and would support PaceAggregationInSeparateSpec, and would be
 happy to drop PaceAggregationDocument and PaceAggregationDocument2 if
 that were the case.
Yes, with either option (PaceProfile or PaceProfileAttribute).
- James M Snell
Antone Roundy wrote:
+1.
I may have missed something, but I didn't see it specified whether one 
document could list more than one profile or not.  I think it should not 
be allowed.  With multiple profiles mixed, it would be more difficult to 
figure out exactly what to expect, and I don't expect it to be 
necessary--if you want to specify a feed that's a hybrid of two 
profiles, create another profile that describes exactly what you're after.

Profiles could take care of the job of specifying how to create what I 
recently referred to as Collection Documents and Archive Documents 
(identical except that multiple versions of a particular entry would be 
allowed in Archive Documents).  I would be fine with dropping 
PaceArchiveDocument, and allowing content and summary in head 
(PaceCommentFeeds--let's keep link/@rel=comments though) if this is 
accepted.

Question: If head-in-entry were removed from the spec, could a profile 
indicate that entry could contain a head that specified the feed 
data relevant to the entry?  I'd be in favor of handling aggregation 
that way, and would support PaceAggregationInSeparateSpec, and would be 
happy to drop PaceAggregationDocument and PaceAggregationDocument2 if 
that were the case.





Re: PaceProfile

2005-02-07 Thread Robert Sayre
-1, I guess. This Pace proposes an organization of the spec which 
assumes we accept PaceProfileAttribute and/or keep the version 
attribute. I think the layout is reasonable for that scenario, but it 
overlaps with PaceExtensionConstruct and some others. I don't really see 
much reason to do a Pace for this. Perhaps it's meant to counter 
PaceOrderSpecAlphabetically.

I'm not really opposed to either Pace, but these are editorial issues, 
which the WG can address after the format is locked down. Right now, I 
feel they are just confusing matters. I think we should close them and 
deal with this problem around Feb 21ish[0].

Robert Sayre
[0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html


Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Robert Sayre
Sam Ruby wrote:
I can easily sit back and adopt a wait and see and I told you so 
attitude, but by now it should be obvious that I care too much about the 
success of this format and protocol to do that.

After watching this WG fail to communicate clearly on this matter, and 
make a variety of arcane XML serialization mistakes in the course of 
discussion, it's clear to me that Sam is right.

+1 to PaceXhtmlNamespaceDiv
Robert Sayre


Re: PaceProfile

2005-02-07 Thread James M Snell
Actually, PaceProfile was proposed prior to PaceProfileAttribute and is 
an independent proposal.  I offered PaceProfileAttribute as a separate 
proposal because 1) PaceProfile didn't really specify any specifics for 
the the @profile attribute beyond suggesting that it be created or that 
@version be modified and 2) I did not think that a complete 
restructuring of the document was really necessary.  I tried to be more 
specific in PaceProfileAttribute.  I am quite certain that Mark has his 
own ideas with regards to PaceProfile and that he would not agree that 
PaceProfile depends on PaceProfileAttribute in any way.  Likewise, 
PaceProfileAttribute has no dependencies on PaceProfile.

- James M Snell
Robert Sayre wrote:
-1, I guess. This Pace proposes an organization of the spec which 
assumes we accept PaceProfileAttribute and/or keep the version 
attribute. I think the layout is reasonable for that scenario, but it 
overlaps with PaceExtensionConstruct and some others. I don't really see 
much reason to do a Pace for this. Perhaps it's meant to counter 
PaceOrderSpecAlphabetically.

I'm not really opposed to either Pace, but these are editorial issues, 
which the WG can address after the format is locked down. Right now, I 
feel they are just confusing matters. I think we should close them and 
deal with this problem around Feb 21ish[0].

Robert Sayre
[0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html




Re: PaceProfile

2005-02-07 Thread Robert Sayre
James M Snell wrote:
I am quite certain that Mark has his
own ideas with regards to PaceProfile and that he would not agree that 
PaceProfile depends on PaceProfileAttribute in any way.  Likewise, 
PaceProfileAttribute has no dependencies on PaceProfile.

Oh! This isn't editorial at all, then. I guess I'd have to see some more 
 spec text, then. I'm not sure what Mark is proposing.

Robert Sayre


Re: PaceProfile

2005-02-07 Thread Sam Ruby
Robert Sayre wrote:
James M Snell wrote:
I am quite certain that Mark has his
own ideas with regards to PaceProfile and that he would not agree that 
PaceProfile depends on PaceProfileAttribute in any way.  Likewise, 
PaceProfileAttribute has no dependencies on PaceProfile.
Oh! This isn't editorial at all, then. I guess I'd have to see some more 
 spec text, then. I'm not sure what Mark is proposing.
I missed that too... otherwise I would have simply put this Pace in the 
Recommended for Closure list.

-1 on this Pace until section 6 is flushed out.
- Sam Ruby


Re: PaceProfile

2005-02-07 Thread Paul Hoffman
-1 because it is incomplete (no text for the new profiles in Section 
6). The specification of those profiles could have a major technical 
effect on the rest of the document.

--Paul Hoffman, Director
--Internet Mail Consortium


PaceProfileAttribute

2005-02-07 Thread Paul Hoffman
-1 because it doesn't feel like it belongs in the core. That is, when 
more developers have real profiles that they want to differentiate 
from the atom core, adding a @profile attribute seems like a good 
extension.

--Paul Hoffman, Director
--Internet Mail Consortium


withdraw PaceFeedRecursive

2005-02-07 Thread Roy T. Fielding
Please withdraw PaceFeedRecursive because forcing everything to
be an entry is sufficient justification to forbid inclusion by
anything other than reference.
The other (still needed) bits are in PaceHeadless.
Cheers,
Roy T. Fieldinghttp://roy.gbiv.com/
Chief Scientist, Day Software  http://www.day.com/


Re: PaceProfile

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 03:41  PM, Sam Ruby wrote:
Robert Sayre wrote:
James M Snell wrote:
I am quite certain that Mark has his
own ideas with regards to PaceProfile and that he would not agree 
that PaceProfile depends on PaceProfileAttribute in any way.  
Likewise, PaceProfileAttribute has no dependencies on PaceProfile.
Oh! This isn't editorial at all, then. I guess I'd have to see some 
more  spec text, then. I'm not sure what Mark is proposing.
I missed that too... otherwise I would have simply put this Pace in 
the Recommended for Closure list.

-1 on this Pace until section 6 is flushed out.
Please finish it!  If it turns out close to the way I understand it 
from what's already there and the discussion thus far, it will keep my 
support.



Re: PaceXhtmlNamespaceDiv

2005-02-07 Thread Julian Reschke
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv

-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.
Same here: -1
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Service Constructs?

2005-02-07 Thread Robert Sayre
Looks like we forgot to write a formal Pace for removing the protocol 
elements.

Proposed by Julian:
http://www.imc.org/atom-syntax/mail-archive/msg12887.html
+1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and 
Underwood.

Robert Sayre


Re: PaceProfileAttribute

2005-02-07 Thread James M Snell
Paul Hoffman wrote:

 -1 because it doesn't feel like it belongs in the core. That is, when
 more developers have real profiles that they want to differentiate from
 the atom core, adding a @profile attribute seems like a good extension.
Hmm. the challenge with this assertion is that the atom spec as it 
stands today, does not give someone the option of being able to override 
the metadata containment requirements as specified by the core.  Nor 
does it give any indication how such redefinition should occur.  This 
spec does not introduce any other profiles, it just provides the 
framework under which profiles can be created and cooks that into the 
core so that doing so can be done in a consistent, reliable manner.

Further, one would need to consider how a @profile differs from a 
@version and the namespace attribute, etc.  This proposal replaces 
@version completely with the @profile mechanism.  The namespace is used 
to identify the semantics of the individual elements themselves while 
the profile is used to identify the containment requirements.  As the 
spec stands currently, the relationship between atom 
[EMAIL PROTECTED] requirements+element semantics is muddled 
up.  Is it possible for someone to modify containment requirements for a 
specific use case while adhering to the same atom namespace?  The 
@version attribute is defined such that it relates to Atom spec version. 
 Does @version reflect element semantics or containment 
requirements or both?  This proposal says, namespace==element semantics, 
@profile=containment requirements and provides a clear, consistent 
approach to handling different/multiple @profiles.  That is a far cry 
from the minimal and far-from-helpful 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 
is unstructured text.

Also, as others have pointed out, the profile attribute mechanism could 
be used to handle cases such as defining the requirements for an archive 
as opposed to creating a new top level archive element.

Bottom line: while @profile COULD be added as an extension, I think it 
is much more valuable in the core as a replacement to @version.

- James M Snell


Re: Service Constructs?

2005-02-07 Thread James M Snell
+1 on this also. They shouldn't be in the core
- James M Snell
Robert Sayre wrote:
Looks like we forgot to write a formal Pace for removing the protocol 
elements.

Proposed by Julian:
http://www.imc.org/atom-syntax/mail-archive/msg12887.html
+1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and 
Underwood.

Robert Sayre




  1   2   >