Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready

[Henry Story]

If you just want to stick to syntax, then please leave the pace
as it is. Don't try to impose a model through syntax and then
argue that people can't argue about the model that you are
surreptitiously trying to introduce.
The current syntax (allowing multiple ids in a feed per feed document)
worked very well for both models.
Henry Story
On 8 Feb 2005, at 00:27, Bill de hÓra wrote:
Henry Story wrote:
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.
Choice of model will not make an iota of difference to the core spec. 
I could sit here and claim that sliding window makes reordering 
impossible - that would be about as jaundiced and prejudicial a view 
as I've seen spat out about current state. What good is this doing?

Can we please desist from arguing over models? Five years out we can 
determine if there is a sufficiently powerful model to explain 
syndication based on the data. Not now.

cheers
Bill

Re: PaceHeadless

[Eric Scheid]

On 8/2/05 4:38 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:

> Agree, feeder is ugly. but head should still go away.  My preference
> would be a link based alternative.
> 
> 
>  ...
>  
>...
>
>  
> 

+1

Re: PaceHeadless

[James M Snell]

Agree, feeder is ugly. but head should still go away.  My preference 
would be a link based alternative.


  ...
  
...

  

- James M Snell
Eric Scheid wrote:
-1 atom:feeder is ugly

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 8, 2005, at 01:55, Sam Ruby wrote:
Can I get one of you three to mock up what Tim's feed should look like?

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The 
Mouse BT from some outfit
...

OR

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The Mouse BT from some 
outfit
...

OR

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The Mouse BT from some 
outfit
...

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceHeadless

[Eric Scheid]

-1 atom:feeder is ugly

Re: PaceProfile

[Robert Sayre]

Bill de hÓra wrote:
The problem is that switching on the content of an element/attribute is 
Atom's get out of jail card wrt extensibility. It is the default Atom 
extensibility model, as it's the only game we have to play that doesn't 
involve screwing about with the meaning of existing core data items or 
adding new core items. Allowing people to add elements in other 
namespaces under atom:feed or atom:entry and calling that extensibility 
is like saying a new carpet in my living room is an extension to my 
house - it's a crashingly weak approach.
So, is that a +1 or a -1 on the profile concept?
Robert Sayre

Re: PaceHeadless

[Robert Sayre]

+1, there's no reason for atom:head.
Robert Sayre

Re: PaceRepeatIdInDocument

[Sam Ruby]

Antone Roundy wrote:
-1 (yeah, I know I'm the author) if we define some way to create what 
I've recently referred to as Archive Documents.  My preferred method is 
based on PaceProfile (more on that to come).
Also -1 unless there is a way for someone to unambiguously declare that 
a document may contain multiple versions of of a single element.

Even so, I am not convinced that most aggregator authors are up to 
disambiguating versions.

- Sam Ruby

Re: PaceProfile

[Graham]

On 8 Feb 2005, at 1:08 am, Eric Scheid wrote:
for example, a profile for a (S)SFF (remember them?) would allow 
entries as
minimal as this:


some-id

...

That's not an entry so it doesn't need to be an atom:entry:

 
   ...
 
 
 some-id
 
 ...
  
  

(In the general case, I'd like non-compatible profiles to use different 
top-level/collection elements)

Graham

PaceArchiveDocument

[Antone Roundy]

If we adopt PaceProfile, then -1, otherwise +1.  I'd also be fine with 
losing the  elements and just having *

PaceAggregationDocument, PaceAggregationDocument2

[Antone Roundy]

If we adopt PaceProfile and drop head-in-entry (which could be added 
back in by a profile), -1 to both, otherwise +1 to 
PaceAggregationDocument2, or lacking that, PaceAggregationDocument.

Re: tagline -> subtitle

[Paul Hoffman]

At 12:53 AM + 2/8/05, Graham wrote:
Did this need a Pace? It seems to have got fairly unanimous support.
No pace needed for editorial changes such as renaming elements or 
attributes if there is good agreement. The editors know full well if 
they make a change that angers the WG, the pitchforks will be drawn.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PaceProfile

[James M Snell]

With PaceProfileAttribute, weakening cardinality is possible with the 
strongly worded statement that new profiles SHOULD be defined so that 
they are backwards compatible with the core (thereby making weakened 
cardinality Not A Good Idea).  Also, I would argue that if multiple 
profiles are allowed and are applied, the profile with the highest 
cardinality takes precendence.  In other words, if someone declares that 
they are applying both the core profile and a profile that makes 
optional some element the core requires, the core takes precendence and 
the element is required.

- James M Snell
Eric Scheid wrote:
On 8/2/05 10:44 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:

I'm not sure they are that antagonistic, but I agree with Paul when he
says they could be added later. If profiles aren't supposed to matter to
"Core Atom" processors, why not put our money where our mouth is and
make profiles declare themselves in their own namespace?

would it be acceptable to use a profile to weaken cardinality rules?
for example, a profile for a (S)SFF (remember them?) would allow entries as
minimal as this:

some-id

...

how might this be represented in a namespaced extension instead?
e.

Re: PaceDatesXSD

[Eric Scheid]

> PaceDatesXSD

+1

Re: PaceArchiveDocument

[Eric Scheid]

> PaceArchiveDocument

-1

this looks like a backdoor to feeds in feeds.

Re: PaceLangSpecific

[Eric Scheid]

> PaceLangSpecific

+1, but also needed for atom:generator

hmmm ... if we have xml:lang on , we are going to also need
@hreflang for , because while some types of referenced
content can have the language attached, at type="text/plain" cannot.

Re: PaceMustBeWellFormed

[Eric Scheid]

> PaceMustBeWellFormed

-1 - needs to be re-written to avoid use of "well-formed" which has a
specific meaning to some religious fanatics ;-)

+1 to the general intent of this pace: explaining how publishers might get
tripped up by the obscurities of technology and render their feed "broken" 

Re: PaceEntriesElement

[Eric Scheid]

> PaceEntriesElement

-1

Re: PaceRepeatIdInDocument

[Eric Scheid]

> PaceRepeatIdInDocument

+1

I'm happy with allowing multiple entries with the same ID in the one 
instance. Aggregators already must handle the case of seeing the same ID in
some way, since that ID could quite reasonably have been in a previous
edition of the  resource.

Re: PaceCommentFeeds

[Eric Scheid]

> PaceCommentFeeds


+1 to link/@rel="comment"

-1 to feed/head/content

+0 to feed/head/summary -- this could be informative even for non-comments
feeds, a descriptive meta-data element

Re: PaceRemoveInfoAndHost

[Eric Scheid]

> PaceRemoveInfoAndHost

+1

Re: PaceFeedState

[Eric Scheid]

> PaceFeedState

-1 to all the traversal shenanigans being in the core

+1 to link/@rel=[next|prev|self]

Re: PaceProfile

[Eric Scheid]

On 8/2/05 10:44 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:

> I'm not sure they are that antagonistic, but I agree with Paul when he
> says they could be added later. If profiles aren't supposed to matter to
> "Core Atom" processors, why not put our money where our mouth is and
> make profiles declare themselves in their own namespace?

would it be acceptable to use a profile to weaken cardinality rules?

for example, a profile for a (S)SFF (remember them?) would allow entries as
minimal as this:


some-id

...


how might this be represented in a namespaced extension instead?

e.

Re: PaceRemoveVersionAttr

[Eric Scheid]

> PaceRemoveVersionAttr

-0

I suspect there are good social reasons to keep @version

Re: PaceLinkEnclosure

[Eric Scheid]

> PaceLinkEnclosure

+1 to @rel="enclosure", or @rel="attachement" as some want it

Re: PaceClarifyDateUpdated

[Eric Scheid]

> PaceClarifyDateUpdated

+1. 

atom:updated is not atom:modified or dc:modified, and we need to guard
against that if the special semantics of atom:updated are not be smothered
under a flood of atom:modified pollution.

Re: PaceFeedRecursive

[Eric Scheid]

> PaceFeedRecursive

-1

Re: PaceAggregationDocument, PaceAggregationDocument2

[Eric Scheid]

> PaceAggregationDocument
> PaceAggregationDocument2

-1

Re: PaceNoFeedState

[Eric Scheid]

> PaceNoFeedState

+1

the alternative proposed so far contains instructions of traversal of feed
documents ... when instead there may be other mechanisms.

For example: Bob could work up a system of pushing a series of entries in
response to a request for "all entries between date X and date Y".

Re: PaceLinkRelVia

[Eric Scheid]

> PaceLinkRelVia

+1

Re: PaceIconAndImage, PaceMultipleImages

[Eric Scheid]

> PaceIconAndImage

+1

+1 to renaming atom:image to atom:logo

> PaceMultipleImages

-1 : multiple language variants of anything seems to be well-kyboshed
anywhere in atom

Re: PaceXhtmlNamespaceDiv

[Eric Scheid]

> PaceXhtmlNamespaceDiv

+1 

Re: PaceHeadless

[Eric Scheid]

> PaceHeadless

-1

Re: PaceCollection

[Eric Scheid]

> PaceCollection

+1

yeeouch - I had no idea just how extensive the difference in opinions as to
what a  represents.

Re: PaceJoinSectionSixAndTen

[Eric Scheid]

> PaceJoinSectionSixAndTen

-1

Re: PaceAggregationInSeparateSpec

[Eric Scheid]

> PaceAggregationInSeparateSpec

+1

Re: PaceEntryOrder

[Eric Scheid]

> PaceEntryOrder

+1

Re: PaceProfile

[Bill de hÓra]

Robert Sayre wrote:
James M Snell wrote:
Further, the core spec still does not expressly allow extensions to 
change the containment requirements.  
That's right.
With good reason - as we have no processing model in place to explain 
how such extensions should be evaluated we have no business allowing them.


Thus far, the only thing an extension can do is add new types of 
namespace qualified metadata elements.
Yes.
This is not the case - we are using @rel to extend (scoped to links).
cheers
Bill

Re: tagline -> subtitle

[Graham]

Did this need a Pace? It seems to have got fairly unanimous support.
Graham
On 2 Feb 2005, at 3:37 pm, Graham wrote:
Any chance of renaming atom:tagline to atom:subtitle? The two sample 
feeds posted today have the taglines "ongoing fragmented essay by Tim 
Bray" and "WebDAV related news". Aren't taglines meant to be funny or 
catchy or clever?

The relevant definitions from dictionary.com are:
 tagline: An often repeated phrase associated with an individual, 
organization, or commercial product; a slogan.
 subtitle: A secondary, usually explanatory title, as of a literary 
work.

The second seems much broader and more useful, and there's nothing 
stopping you using a slogan as subtitle.

Graham

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

[Roy T. Fielding]

On Feb 7, 2005, at 5:15 AM, Henry Story wrote:
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...
Yes, though it seems to me that you swapped the meanings of
funcId and equivId somewhere between your definitions and your
example, so I lost interest.
I gave an example that did not conflict with a reasonable design.
On the contrary, you gave an example in which a feed contained
two entries with the same id (where id here is defined as meaning
the author intends this entry to supplant any prior entries with
the same id).  It is not reasonable to include more than
one entry with the same id within the same feed representation,
since all entry representations in the feed representation must
validly represent the state of the feed at the time that the
feed representation was generated (otherwise, it is not a feed
representation at all -- it is an archive, history, ... whatever).
This whole discussion presumes that it is not desirable to send
all versions of all entries as part of the feed; i.e., the author
specifically intends old versions of an entry to never appear in
later versions of the feed.  If you don't agree with that
presumption, then I think you are talking about something other
than what most bloggers call a feed.
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.
Okay, but only if you promise not to extend this discussion on
the atom list -- take it elsewhere if you wish to puncture my
opinion -- atom should be allowed to progress in peace without
invoking the defenders of RDF universality.
:
   There are several aspects of meaning in RDF which are ignored
   by this semantics; in particular, it treats URI references as
   simple names, ignoring aspects of meaning encoded in particular
   URI forms [RFC 2396] and does not provide any analysis of
   time-varying data or of changes to URI references. It does not
   provide any analysis of indexical uses of URI references, for
   example to mean 'this document'. Some parts of the RDF and RDFS
   vocabularies are not assigned any formal meaning, and in some
   cases, notably the reification and container vocabularies, it
   assigns less meaning than one might expect. These cases are
   noted in the text and the limitations discussed in more detail.
   RDF is an assertional logic, in which each triple expresses a
   simple proposition. This imposes a fairly strict monotonic
   discipline on the language, so that it cannot express
   closed-world assumptions, local default preferences, and
   several other commonly used non-monotonic constructs.
RDF has no capacity for temporally qualified assertions, no
conceptual understanding of sink-like services, and very little
habit of distinguishing between resources and representations
(though it does have the capacity to deal with representations
as b-nodes).  Likewise, it does not differentiate between
identification and use, which means it cannot be used to describe
the many times in which a single URI can be used for many
different things even if it only identifies (directly) one thing.
The same comments apply to OWL.
As previously stated, understanding the meaning of a resource
is all about time.  Trying to describe the Web without that
dimension is a hopelessly futile effort that leads to such
absurdities as declaring some URIs as being "invalid" or
"inappropriate" simply because their use does not fit the
artificial model of a timeless world.
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.
My position is not based on seniority.
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.)
No, as far as I know, there have been no recent developments that
would cause the semantic web to reconsider its central assumptions.
Cheers,
Roy T. Fielding
Chief Scientist, Day Software  

Re: PaceProfile

[Bill de hÓra]

Robert Sayre wrote:
So, you're looking for a way to include a "schema" association in the 
feed, and you want a standard way to do it. The only processors that 
will do anything useful with this information are those that know about 
the "profile".



  GottaHaveCategories

...

You're using Atom, and processors who know about your additional 
requirements will know about your schema. What you're asking is for the 
spec to lend weight to your extensions, and I'm not very positive about 
that.
The problem is that switching on the content of an element/attribute is 
Atom's get out of jail card wrt extensibility. It is the default Atom 
extensibility model, as it's the only game we have to play that doesn't 
involve screwing about with the meaning of existing core data items or 
adding new core items. Allowing people to add elements in other 
namespaces under atom:feed or atom:entry and calling that extensibility 
is like saying a new carpet in my living room is an extension to my 
house - it's a crashingly weak approach.

It seems to me then that if there's room for believing that there is a 
set of potential switches, there is room for discussing a core 
element/attribute to paste them into.

The same argument you make against @profile can be made about @rel. 
Indeed you could do all this profiling stuff with a new range of values 
and allowing @rel on the atom:feed element, or less obvious, into the 
atom:feed/atom:[EMAIL PROTECTED] part. Either of which I think I'd prefer - as 
we only have extensibility approach it doesn't add value of 
comprehension to call its slot by two different names.

cheers
Bill

Re: PaceProfile

[Robert Sayre]

James M Snell wrote:
Further, the core spec 
still does not expressly allow extensions to change the containment 
requirements.  
That's right.
Thus far, the only thing an extension can do is add new 
types of namespace qualified metadata elements.

Yes.
Robert Sayre

Re: PaceProfile

[James M Snell]

So, you're looking for a way to include a "schema" association in the 
feed, and you want a standard way to do it. The only processors that 
will do anything useful with this information are those that know about 
the "profile".



  GottaHaveCategories

...

I don't see the value in this in that it opens up the possibility that 
every extension that wants to change the containment requirements could 
do so in some different way.  It doesn't provide any guidance on how to 
change those requirements in a backwards compatible way, nor does it 
help figure out how to reconcile a situation in which multiple such 
extensions are applied to the same feed/entry.  Further, the core spec 
still does not expressly allow extensions to change the containment 
requirements.  Thus far, the only thing an extension can do is add new 
types of namespace qualified metadata elements.

You're using Atom, and processors who know about your additional 
requirements will know about your schema. What you're asking is for the 
spec to lend weight to your extensions, and I'm not very positive about 
that.

No, what I'm asking for is a single, consistent way of declaring the use 
of profiles and the ability to make containment requirements independent 
of the element definitions.  The spec is not lending weight to anything 
but its own core profile.

Robert Sayre

Re: PaceProfile

[Walter Underwood]

--On February 7, 2005 7:13:21 PM -0500 Robert Sayre <[EMAIL PROTECTED]> wrote:
>
> So, you're looking for a way to include a "schema" association in the feed,
> and you want a standard way to do it. The only processors that will do 
> anything
> useful with this information are those that know about the "profile".

Sounds like a job for .

Or a processing instruction, but I seem to be the only person that likes those.

wunder
--
Walter Underwood
Principal Architect, Verity

Re: PaceXhtmlNamespaceDiv

[Bill de hÓra]

Sam Ruby wrote:
Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.
>
atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.
Agreed (but we have already decided to allow that possibility at the 
container level). Still +1.

cheers
Bill

Re: PaceProfile

[Robert Sayre]

James M Snell wrote:
Robert Sayre wrote:
 > I'm not sure they are that antagonistic, but I agree with Paul when he
 > says they could be added later. If profiles aren't supposed to matter to
 > "Core Atom" processors, why not put our money where our mouth is and
 > make profiles declare themselves in their own namespace?
Suppose I want to require that a feed head MUST specify at least one 
category element for a specific type of use case. (just pulled the 
example from the air).  I want folks to be able to know that I'm using 
alternative containment requirements.  I want everything else to remain 
the same so that processors that aren't familiar with my modified 
profile can simply ignore it and process according to the core. Just so 
I understand exactly what you're thinking on this, how would I handle 
this using the extension approach?  Could you provide some strawman 
angle brackets?
So, you're looking for a way to include a "schema" association in the 
feed, and you want a standard way to do it. The only processors that 
will do anything useful with this information are those that know about 
the "profile".



  GottaHaveCategories

...

You're using Atom, and processors who know about your additional 
requirements will know about your schema. What you're asking is for the 
spec to lend weight to your extensions, and I'm not very positive about 
that.

Robert Sayre

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Bill de hÓra wrote:
Sam Ruby wrote:
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)
Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.
Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.

atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.

- Sam Ruby

Re: PaceProfile

[James M Snell]

Robert Sayre wrote:
> I'm not sure they are that antagonistic, but I agree with Paul when he
> says they could be added later. If profiles aren't supposed to matter to
> "Core Atom" processors, why not put our money where our mouth is and
> make profiles declare themselves in their own namespace?
Suppose I want to require that a feed head MUST specify at least one 
category element for a specific type of use case. (just pulled the 
example from the air).  I want folks to be able to know that I'm using 
alternative containment requirements.  I want everything else to remain 
the same so that processors that aren't familiar with my modified 
profile can simply ignore it and process according to the core. Just so 
I understand exactly what you're thinking on this, how would I handle 
this using the extension approach?  Could you provide some strawman 
angle brackets?

- James M Snell

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
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
Can I get one of you three to mock up what Tim's feed should look like?
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Bill de hÓra]

Sam Ruby wrote:
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)
Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.

I'm +1 on this pace, sometimes a judicious hack is the right thing to 
do. I suspect it could result in  nesting - call it gut feeling 
(it's an escaping mechanism after all).

cheers
Bill

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

[Bob Wyman]

Antone Roundy wrote:
> 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.
Sorry, we don't have precise numbers. I've done the calculations in
the past (it's a fairly expensive process) but then haven't kept the
detail... I did the calculations for me, not for review or publication. But,
you are absolutely correct in your guess that the savings of push over
RFC3229+feed is less dramatic then the savings over the normal file polling.
This was one of the motivations for our proposing RFC3229+feed in the first
place. We wanted to make polling as efficient as possible since we get
polled a lot and since we poll a lot... RFC3229+feed diminishes the
bandwidth savings you get from push but doesn't eliminate those savings.
That weakens the argument for push, but results in improving the overall
system.

> 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.
I agree that this should not be "either-or". I would be happy if the
spec said something like "multiple entries with the same atom:id MAY appear
in a single feed document." I don't think it would be reasonable to insist
that people insert all changes in their feeds. My goal is simply to permit
this, not force it. Whether the feed contains all versions of entries should
be up to the feed writer.

bob wyman

Re: PaceXhtmlNamespaceDiv

[Roger B.]

I'm +1 when wearing my aggregator hat, and indifferent from a
publishing perspective.

--
Roger Benningfield
JournURL

Re: PaceProfile

[Robert Sayre]

Graham wrote:
Profiles seem to be a way for people who disagree with decisions made 
by this working group to invent their own Atom format and claim it is 
valid Atom. No thank you.
I'm not sure they are that antagonistic, but I agree with Paul when he 
says they could be added later. If profiles aren't supposed to matter to 
"Core Atom" processors, why not put our money where our mouth is and 
make profiles declare themselves in their own namespace?

Robert Sayre

Re: PaceProfile

[James M Snell]

No, profiles are a way of folks to tweak the metadata containment 
requirements of feeds/entries for specific use cases (example: creating 
an archive as opposed to a syndicated feed).  While I cannot speak for 
PaceProfile which does not call out any specific text on the matter, 
with PaceProfileAttribute the production of new profiles that are 
backwards compatible with the core profile is STRONGLY recommended but 
not required.  PaceProfileAttribute assumes a community vetting process 
that optimistically assumes that a) creation of new profiles will be 
fairly rare and b) such profiles will only enjoy broad use if they are 
actually made interoperable with the core.  Folks that attempt to be 
incompatible with the core requirements would have to convince the other 
Atom software providers to support their profile if they wish to achieve 
any level of interoperability.

- James M Snell
Graham wrote:
Profiles seem to be a way for people who disagree with decisions made by 
this working group to invent their own Atom format and claim it is valid 
Atom. No thank you.

-1
Graham

PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready

[Bill de hÓra]

Henry Story wrote:
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.
Choice of model will not make an iota of difference to the core spec. I 
could sit here and claim that sliding window makes reordering impossible 
- that would be about as jaundiced and prejudicial a view as I've seen 
spat out about current state. What good is this doing?

Can we please desist from arguing over models? Five years out we can 
determine if there is a sufficiently powerful model to explain 
syndication based on the data. Not now.

cheers
Bill

Re: PaceProfile

[Graham]

Profiles seem to be a way for people who disagree with decisions made 
by this working group to invent their own Atom format and claim it is 
valid Atom. No thank you.

-1
Graham

Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder]

[Roy T. Fielding]

On Feb 6, 2005, at 6:50 PM, Mark Nottingham wrote:
On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote:
The problem with that statement (about HTTP) is that absence of a 
must-understand in HTTP is not one of its big problems. Yes, I know 
lots of people have talked about it as a limiting factor in the 
syntax of HTTP, but to call it an actual problem would say that it 
prevented some good from being accomplished.
It arguably tipped some people towards SOAP when HTTP would have been 
adequate. That's not a prevention of good, but we've already seen 
enough fragmentation in the syndication world.
Well, arguably, those same applications should have been tipped
into the waste basket in the first place.  But I don't think you
followed my main point: must understand is a mechanism to enable
fragmentation -- its very presence leads away from standardization.
Lack of mU is one of the reasons that HTTP is not fragmented (along
with me being a stubborn pain in the ass).  Hence, it is only a
problem for some applications that were of questionable character,
and it remains unclear whether HTTP would have benefitted by having
a mU feature or if its presence would have led to a complete meltdown.
Things that a syndication format might want to make mandatory are 
copyright controls and micropayments, but both have been shown in 
practice to require either a willingness on the part of the recipient 
to accept that specific restriction (i.e., human intervention and 
understanding) or forceful requirement by the sender (i.e., 
encryption). In both cases, agreements have to be established with 
the user in advance, before they even receive the content, and thus 
do not need a "must understand" feature.
I don't think mU is intended for such things; rather, the case for mU 
could be characterised as extensions that change the operation of the 
protocol in a manner that renders it useless or misleading to try to 
use the feed if you don't know what to do with the extension. It's 
advisory.
Right, but look at my examples and try to think of any others that
would require changes in operation on the behalf of recipients.
There may be others, but I am not aware of any more.
In fact, "must understand" has no value in a network-based 
application except as positive guidance for intermediaries, which is 
something that can still be accomplished under mustIgnore with a bit 
of old-fashioned advocacy.
So, if I can restate your position, you're saying that you don't 
dispute that understanding some extensions may be required, but that 
it isn't necessary to make that visible to the processor, because 
it'll be co-ordinated beforehand (e.g., through market forces, 
out-of-band-communication), correct?
No, my position is that it isn't necessary to include mU in the format.
Within the control data of an interaction protocol, sure, but not
within the payload of completed actions, wherein any such requirements
are far too late and susceptible to abuse.
Just to be clear that I am not completely against mU in
all protocols, that feature does exist in waka because it is
useful when talking through intermediaries.
Roy

Re: Service Constructs?

[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

Re: PaceProfileAttribute

[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

Service Constructs?

[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: PaceXhtmlNamespaceDiv

[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
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceProfile

[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.

withdraw PaceFeedRecursive

[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. Fielding
Chief Scientist, Day Software  

PaceProfileAttribute

[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

Re: PaceProfile

[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

Re: PaceProfile

[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

[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

[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: PaceEntryOrder

[Walter Underwood]

--On February 7, 2005 4:27:12 PM -0500 Sam Ruby <[EMAIL PROTECTED]> wrote:
>
> Ultimately, the sentiment that I want conveyed is that publishers are not
> safe to assume that clients will read anything into the order.

And I think that the order should mean "the publisher put them in this order."
The Pace forbids that interpretation.

Clients can reorder things, show only a few, whatever. I'm not restricting
client behavior.

Do other specs in the RSS family say anything about order? If order is
significant in those, then making it not significant in Atom will hurt
interoperability.

Hmm, I can't finding any ordering restrictions in a quick read of RSS 0.91 
and 2.0, but RSS 1.0 does specify ordering.

>From RSS 1.0: 5.3.5 

   An RDF Seq (sequence) is used to contain all the items rather than an
   RDF Bag to denote item order for rendering and reconstruction.

   

wunder
--
Walter Underwood
Principal Architect, Verity

Re: PaceXhtmlNamespaceDiv

[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

[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: PaceProfile

[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  and  levels (independent 
of document arrangement)
* multiple profiles per  
* profile applies just to the  or  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  and profileB requires , processors 
should expect  and .  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  
and profileA requires no fewer than 2 .  If the element contains 
2 , 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  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  could contain a  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  and  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  could contain a  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: PaceProfileAttribute

[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: PaceEntryOrder

[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

PaceHeadless

[Antone Roundy]

-1, but if we do adopt it, let's use some name other than "feeder".

PaceAggregationInSeparateSpec

[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:





...

...

but this:




...

...

Re: PaceEntryOrder

[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

PaceProfile

[Antone Roundy]

+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  and  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  could contain a  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: PaceXhtmlNamespaceDiv

[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  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 s.
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

[David Powell]

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 :)

-- 
Dave

Re: PaceProfileAttribute

[James M Snell]

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.

PaceRepeatIdInDocument

[Antone Roundy]

-1 (yeah, I know I'm the author) if we define some way to create what 
I've recently referred to as Archive Documents.  My preferred method is 
based on PaceProfile (more on that to come).

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 22:44, James M Snell wrote:
Nah, I don't buy it.  XHTML is just a special case of an XML content
Atom has chosen to treat type='XHTML' (as opposed to 
type='application/xtml+xml') as a special case.

wouldn't make any sense (under the assumption that the  
element is top level container) for us to do:


  
...
  
  
...
  

By that logic, you'd have to include the 'html', 'head', 'title' and 
'body' XHTML elements as well. See http://macsanomat.com/atom for an 
example of that. (0.3 was silent on subsetting the XHTML document, so 
logically I had to assume it was not allowed, although the 
ViewSourceClan thought it was.)

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

PaceProfileAttribute

[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

[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  element is 
top level container) for us to do:


  
...
  
  
...
  


I do not follow this example.
The point is that  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

Re: PaceXhtmlNamespaceDiv

[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  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
 

Re: PaceXhtmlNamespaceDiv

[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  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

[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  element is top 
level container) for us to do:


  
...
  
  
...
  

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
 

Re: PaceXhtmlNamespaceDiv

[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

[Antone Roundy]

On Monday, February 7, 2005, at 01:09  PM, Henri Sivonen wrote:
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 
 or before .  Examples of what I'd think was 
acceptable:


...
This is bold
This is against the Pace. Are you really supporting the pace?
Yes, while saying that I would be satisfied with this too--as long as 
the namespace declaration doesn't occur inside  unless in a 
DIV that contains everything else that's in .

OR
This is bold
This is against the Pace, too.
Yep.  Same answer.
OR
This is bold
This one is against the pace as well. Also, the 'b' element would be 
in the same namespace as 'content', which seems wrong.
Gaah!  I left off the  and accidentally put a "/" in the end of 
the  tag.  I meant This is 
bold.  One of those mistakes I could understand, 
but how did I manage to do both at once?

Re: PaceXhtmlNamespaceDiv

[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  element is top 
level container) for us to do:


  
...
  
  
...
  

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

[Anne van Kesteren]

James M Snell wrote:
Yes, sorry I wasn't clear.  Not *only* on ancestor elements. any of the 
following cases should be allowed.

[snip]
And surely || so people who append strings together can 
 do so easily.

I still wonder what the advantage of this conainer is. Especially since, 
as pointed out, the CONTENT element already is the container.

--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Yes, sorry I wasn't clear.  Not *only* on ancestor elements. any of the 
following cases should be allowed.


  

  

  


  

  

  


  

  

  


  

  

  

- 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

[Henri Sivonen]

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!
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceEntriesElement

[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

[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
 

Re: PaceArchiveDocument

[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: PaceEntryOrder

[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: PaceFeedRecursive

[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: PaceXhtmlNamespaceDiv

[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  
or before .  Examples of what I'd think was acceptable:


...
This is bold
OR
This is bold
OR
This is bold
Here's what I think is just plain ugly and shouldn't be allowed:
This is bold
OR
This is bold