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 ==
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 isnt clear on a number of issues. Eg, if an old version of an
entry has some property that
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
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
-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
--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
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
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
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
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
+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
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
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.
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
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
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
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.
*
-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
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
+1. It is a simple clarification that shows the intention without
restricting anyone.
--Paul Hoffman, Director
--Internet Mail Consortium
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
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
-1. Doesn't make sense or add value to the document.
Robert Sayre
Paul Hoffman wrote:
+1. It is a simple clarification that shows the intention without
restricting anyone.
+1. Agree in full.
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
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
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
+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
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
+1. Says all that we need to without getting into HTML too deeply.
Robert Sayre
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
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
-1 to the Pace. The current syntax sufficiently meets the 'support for
archives' charter, and extensions are possible.
-John
+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.
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
--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
+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.
+1, and +1 to calling it attachment instead of enclosure.
+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.
-1: Not enough information. We may not need all the detail of
PaceFormatSecurity, but PaceSecuritySection goes too far the other way.
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,
-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
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
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
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
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
-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.
+1. Low cost, good benefits for interoperability.
+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
+1, with the proviso that I think the first sentence is entirely
meaningless.
Graham
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,
-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
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
+1: if not the whole Pace, then at least link/@rel=comments.
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/
-1: recursion is too complex and bulky.
-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.
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
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=... /
...
+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
+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
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
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
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
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
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
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
-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.
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
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
...
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()) {
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
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...
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.
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
-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
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
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
+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 /
--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
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
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
-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
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
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
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
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
-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
-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
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,
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
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 --
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
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
+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
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
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
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
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
I'm +1 when wearing my aggregator hat, and indifferent from a
publishing perspective.
--
Roger Benningfield
JournURL
1 - 100 of 136 matches
Mail list logo
