Should one not then to make atom:update a MAY?
We don't really need 2 MUST dates.
Henry
On 16 May 2005, at 00:12, David Powell wrote:
PaceAllowDuplicateIDs received some opposition because of its use of
atom:updated to differentiate multiple revisions of an entry [1][2]
[3].
I've posted a couple
Tim Bray wrote:
On May 15, 2005, at 9:43 PM, Robert Sayre wrote:
evilExtension /
Legal? Which part of the spec rules it out?
No part. Per
http://www.atompub.org/2005/04/18/draft-ietf-atompub-format
-08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules
for how to handle it,
Graham wrote:
I'd like to propose an alternative to atom:modified? I've mentioned
this a couple of times before over the last two years, but anyway:
The only properties of atom:modified we're interested in are:
1) That different versions have different dates
2) Sorting chronologically puts the
On 16/5/05 8:31 PM, Graham [EMAIL PROTECTED] wrote:
The only properties of atom:modified we're interested in are:
1) That different versions have different dates
2) Sorting chronologically puts the versions in the correct order
This is to say, the absolute value of the date is irrelevant.
On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote:
The benefit the Web derived from HTML's
implicit-but-universally-implemented MustIgnore rule; it introduced
enough slack into the system that people could experiment without
breaking things.
Don't you think the Feed Validator should flag my
On 16 May 2005, at 2:02 pm, Eric Scheid wrote:
what about comparing that entry against other entries? how do you
sort a set
of entries into chrono order?
We have atom:updated and atom:published for that.
The value does not need to correspond to any particular event in an
entries life-cycle.
On 16 May 2005, at 5:16 pm, Eric Scheid wrote:
if you want to sort by updated or published, but not for most recently
changed (even if not 'significantly')
Well yes. So? I consider atom:modified to be unfeasible anyway for
all sorts of reasons, so we're not losing any capability here.
What if
On Monday, May 16, 2005, at 10:59 AM, Tim Bray wrote:
On May 16, 2005, at 6:27 AM, Robert Sayre wrote:
On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote:
The benefit the Web derived from HTML's
implicit-but-universally-implemented MustIgnore rule; it introduced
enough slack into the system that people
On 16 May 2005, at 6:06 pm, Eric Scheid wrote:
I'm saying that atom:version is an inferior proposition as compared to
atom:modified. Your original premise of there being only two
properties
we're interested in is faulty.
With respect to allowing duplicate ids, it isn't.
Graham
On 16 May 2005, at 5:59 pm, Tim Bray wrote:
i)
Don't you think the Feed Validator should flag my example as invalid?
No.
ii)
I actually thought that what we meant was what the spec said, and
that this was the (very reasonable) outcome of our discussion on
MustUnderstand. That means that if
On May 16, 2005, at 10:44 AM, Robert Sayre wrote:
I am not looking for a repeat of that discussion. Atom 1.0 Processors
cannot distinguish between markup added later on by the IETF and
markup added by a third party, so the processing rules must remain as
they are. That doesn't mean we should allow
Robert Sayre wrote:
On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote:
My problem is that putting text in the format spec saying Nobody but
the IETF can extend the namespace feels empty and useless, are we
going to send Marshall Rose over to beat up anyone who tries?
It will happen and we won't be
Tim Bray wrote:
On May 16, 2005, at 10:44 AM, Robert Sayre wrote:
I am not looking for a repeat of that discussion. Atom 1.0 Processors
cannot distinguish between markup added later on by the IETF and
markup added by a third party, so the processing rules must remain as
they are. That doesn't mean
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote:
My problem is that putting text in the format spec saying Nobody but
the IETF can extend the namespace feels empty and useless, are we
going to send Marshall Rose over to
Robert Sayre wrote:
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote:
My problem is that putting text in the format spec saying Nobody but
the IETF can extend the namespace feels empty and useless, are we
going to send Marshall
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
I can think of a couple things. One would be collisions (which Sam
mentioned).
I don't understand- maybe I'm looking at the wrong post?
http://www.imc.org/atom-syntax/mail-archive/msg15236.html
Sam is saying that the IETF can't add a
Robert Sayre wrote:
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
I can think of a couple things. One would be collisions (which Sam
mentioned).
I don't understand- maybe I'm looking at the wrong post?
http://www.imc.org/atom-syntax/mail-archive/msg15236.html
Sam is saying that the IETF
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
I can think of a couple things. One would be collisions (which Sam
mentioned).
I don't understand- maybe I'm looking at the wrong post?
Robert Sayre wrote:
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
I can think of a couple things. One would be collisions (which Sam
mentioned).
I don't understand- maybe I'm looking at the wrong post?
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
The spec allows anyone to add stuff to the Atom namespace, so the IETF
will have to read everyone's documents before they add something to
the Atom namespace.
The spec does no such thing; that's a psychotic interpretation at best.
http://www.intertwingly.net/wiki/pie/PaceOtherVocabularies
== Abstract ==
Ban non-IETF use of the Atom namespace.
== Status ==
Open
== Rationale ==
Keep extensions in other namespaces, so the Atom namespace can be
safely extended by the IETF.
== Proposal ==
=== 6.1 Extensions From
On May 15, 2005, at 10:24 AM, Tim Bray wrote:
On May 14, 2005, at 11:02 AM, A. Pagaltzis wrote:
The atom:content element either contains or links to the
full content of the entry. An atom:entry containing an
atom:content element MUST be a complete representation of
the entry.
-1
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Only, and this is not a joke, if you agree to add the text What this
specification doesn't ban, it allows. Let's leave no room for doubt as
to the spirit of interpretation.
Future versions of this specification could add new elements and
Robert Sayre wrote:
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Only, and this is not a joke, if you agree to add the text What this
specification doesn't ban, it allows. Let's leave no room for doubt as
to the spirit of interpretation.
Future versions of this specification could add new
Robert Sayre wrote:
Software written to conform
to this version of the specification will not be able to process such
markup correctly and, in fact, will not be able to distinguish it from
markup error.
Please replace that sentence with something reemphasizing the MustIgnore
rule.
Stating that
On 5/16/05, Sam Ruby [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Software written to conform
to this version of the specification will not be able to process such
markup correctly and, in fact, will not be able to distinguish it from
markup error.
Please replace that sentence with
Does this imply that this (or another IETF) Working Group cannot mint
an Atom extension without putting it into a new namespace, or changing
the version number?
If so, I think it's a needless constraint. This WG might come up with a
backwards-compatible extension and want to put it in the Atom
On 5/16/05, Mark Nottingham [EMAIL PROTECTED] wrote:
Does this imply that this (or another IETF) Working Group cannot mint
an Atom extension without putting it into a new namespace, or changing
the version number?
They would have to bump the version number. That was the idea behind
On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote:
Too terse - I don't understand why you're asking this. But if you really
think that we allow everything we don't ban, we should say that
somewhere in the spec.
hmm. I could write that Pace if you want, but maybe it would be more
productive
(BI just had another idea:
(B
(BWhy don't we use a totally different element name, rather than div?
(BWhat about e.g. wrapper? This could be pro-forma in the XHTML Namespace,
(Bbut as this isn't handed over to the XHTML rendering engine (as far as
(BI understand), it wouldn't matter. Also,
-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-atom-
[EMAIL PROTECTED] On Behalf Of Kevin Marks
Subject: Re: Autodiscovery
On May 6, 2005, at 12:21 PM, Bob Wyman wrote:
Sjoerd Visscher wrote:
[HTML 4.01 says:] This attribute describes the relationship from
the
31 matches
Mail list logo
