James Snell wrote:
That's right. Besides, HeadInEntry is trivial to do as an extension, so
there's no reason to leave it in.
I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs. That
mechanism does not have to be
On 4 Feb 2005, at 09:05, James Snell wrote:
Bottom line: In my opinion, the parent feed is just as core to the
entries metadata as is the date it was updated or any of the other
core elements. It *could* be defined as an extension, but I feel it
is better handled in the core.
I have heard
James Snell wrote:
I like the fundamental idea here, but there are a couple of issues:
1. There needs to be a clear description of what a profile is.
2. There needs to be a clear description of how profiles are defined
3. There needs to be a clear description of how profiles are handled
[...]
On 4/2/05 6:14 PM, Robert Sayre [EMAIL PROTECTED] wrote:
leaving things as they are
and deferring deciding how to handle aggregation would irreversibly
enshrine HeadInEntry into the format, which all of the current
organizational proposals are trying to replace.
That's right. Besides,
I am getting sick of arguing with you people. :)
Here is my opinion on every open issue, FWIW. I doubt any of my opinions
will be controversial. You might disagree with one or two of them, but
I'm guessing I predicted the WGs feelings pretty well. It's probably a
waste of your time to argue
On 4/2/05 6:48 PM, James Snell [EMAIL PROTECTED] wrote:
I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs. That
mechanism does not have to be atom:head, but it does need to be part
of the core.
link rel=feed
James Snell wrote:
6. Handle the problem in a non-core extension.
I'm inclined to keep our options open on these use-cases being in or out
of core. We don't have an extension mechanism yet other than
atom:[EMAIL PROTECTED] Certainly Atom format work to date hasn't been framed
as getting the
I just had a thought (astounding!)
If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone to produce
I have heard interesting arguments It's all about the Entries, stupid!
that made the opposite assessment: namely that the entries are what is
important, and that what feed an Entry is part of, is a accident of
life.
The idea there is that Entries are the stand alone entities. They can
be
Mark Nottingham wrote:
I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm.
I have a spam throttle that limits the number of unique pages a person
who is not logged in can edit per hour. I'll send you login info.
- Sam Ruby
Eric Scheid wrote:
I just had a thought (astounding!)
If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone
Bill,
I'm sorry, I don't think I get what you're saying; the words all make
sense, but I don't know how you got here.
Atom currently constrains feed data (e.g., you MUST have a title, there
MUST only be one) based on the most common use case; bloggling/news
syndication. How does this move
http://www.intertwingly.net/wiki/pie/PaceAggregationDocument2
Simplified version of PaceAggregationDocument: adds an aggregation
document element without attempting to redefine all Atom elements as
either metadata or containers in order to make the impact on the
current specification easier to
On Friday, February 4, 2005, at 01:29 AM, Bob Wyman wrote:
4. We've been talking about HeadInEntry ever since I proposed it
back in June at the Atom Community meeting. On numerous occasions, the
group
as a whole has rejected the various feed of feed proposals as overly
complex and unnecessary.
/ Mark Nottingham [EMAIL PROTECTED] was heard to say:
| +1
|
| Welcome to the club :)
+1. I'll join. :-)
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | A man may by custom fortify himself
The 05 draft of the Atom format says:
3.3 Date Constructs
A Date construct is an element whose content MUST conform to the
date-time BNF rule in [RFC3339].
I'm actually using xsd:dateTime in the RELAX NG grammar and I went off
to look at RFC 3339 thinking I might write a
Mark Nottingham wrote:
Bill,
I'm sorry, I don't think I get what you're saying; the words all make
sense, but I don't know how you got here.
[../]
The Pace doesn't place any requirements on Atom Processors WRT @profile;
it's just an advisory flag that tells it what kinds of metadata it can
On Thursday, January 27, 2005, at 09:08 AM, Antone Roundy wrote:
Also, why limit this to feed/head, and not entry?
If we ARE going to limit images to feeds, then please, let's change the
name to logo. If it were logo, I'd agree it doesn't belong in
entry.
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2
Robert Sayre wrote:
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| Robert Sayre wrote:
[...]
| I agree. I was just writing a protocol implementation in Ruby On
| Rails (CRUDs very fast, btw). When I got to the part on date
| formats, I used xsd:dateTime code that was already done, figuring
| that's what
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
[...]
| So what do you do with something like
|
| 2005-02-04T17:20:00
Dunno.
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
values and MUST
Walter Underwood wrote:
--On February 4, 2005 11:18:17 AM -0500 Norman Walsh [EMAIL PROTECTED] wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date
On Feb 4, 2005, at 9:10 AM, Robert Sayre wrote:
My interest is in simplification, not abstraction. For example,
the draft wastes a lot of text talking in the abstract about
various constructs rather than simply defining one element for
each of those constructs.
Person, Date, and Text constructs
To those of you who have been providing Paces before the deadline, our
thanks. This is a reminder that sometime on Monday, Sam is going to do
the *last* rev of AtomPubIssuesList before IETF last call. Both Paul
and I have 100% confidence in Sam's judgement as to which Paces are
well-enough
--On February 3, 2005 11:21:50 PM -0500 Bob Wyman [EMAIL PROTECTED] wrote:
David Powell wrote:
It looks like this might have got lost accidently when the
atom:head element was introduced. Previously Atom 0.3 said [1]:
Ordering of the element children of atom:feed element MUST NOT be
Antone Roundy wrote:
Let me restate this in a way that might lead to action: I have a
sneaking suspicion that we're not going to get consensus on allowing
image and/or icon in entry. If that's the case, would anyone object to
me changing image to logo in the Pace?
That would be bogus a rule.
Norman Walsh wrote:
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
On Friday, February 4, 2005, at 12:37 PM, Robert Sayre wrote:
Antone Roundy wrote:
Let me restate this in a way that might lead to action: I have a
sneaking suspicion that we're not going to get consensus on allowing
image and/or icon in entry. If that's the case, would anyone object
to me
On Feb 4, 2005, at 11:56 AM, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more
than
once in a single feed. (This rule is enforced by FeedValidator for
Atom 0.3
documents... Sam? Mark?)
Sounds
Tim Bray wrote:
On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote:
Is this a joke? This is like saying that the order of the entries in my
mailbox is not significant. Note that ordering a mailbox by date is not
the same thing as its native order.
Except for, Atom entries have a *compulsory*
At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.
The current draft says:
5.8 atom:id Element
The atom:id element is an Identity
* Paul Hoffman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.
The current draft says:
5.8 atom:id Element
The atom:id element is an Identity construct that
On Feb 4, 2005, at 12:29 PM, Paul Hoffman wrote:
At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more
than
once in a single feed.
The current draft says:
5.8 atom:id
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier
doesn't mean you're not able to use it twice to talk about a single
entry;
I disagree, as I've said before. The only literal interpretation is
that you can't serve the same entry
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any two
entries, ever.
I don't read it that way, although I understand how you might infer
that; there's too much wiggle room in the current text for that intent
to be clear.
I.e.,
Bjoern Hoehrmann wrote:
It does not mean that once cannot have multiple versions of the same
entry in a feed (or duplicate entries for that matter).
Conversely it does imply that if you do, you may (and possibly, must)
assume that they are the same entry.
The problem: there's no easy way to
Graham wrote:
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier
doesn't mean you're not able to use it twice to talk about a single
entry;
I disagree, as I've said before. The only literal interpretation is that
you can't serve
--On February 4, 2005 11:44:31 AM -0800 Tim Bray [EMAIL PROTECTED] wrote:
On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote:
Is this a joke? This is like saying that the order of the entries in my
mailbox is not significant. Note that ordering a mailbox by date is not
the same thing as
A really clear way to specify this is to say that an id is a functional
relation between
an entry and a identity construct.
This implies:
-An Entry can only have one id.
-Different Entries can have the same id.
Of course because there is a bit of a confusion as to what is meant by
an Entry
On 4 Feb 2005, at 9:10 pm, Mark Nottingham wrote:
Separately, there's the issue of what it *should* say. Tim and now you
say that you have a good idea of what you want it to say; I'd be very
interested to see how you'd specify that. Can you suggest some spec
text?
As I suggested a couple of
Tim Bray wrote:
I'm with Mnot on this one. Just because it uniquely identifies an
entry, that doesn't mean you can't have two versions of the same
entry in a feed. ... I don't see any reason for ruling them out in a
single feed.
Robert Sayre wrote:
We should probably be more worried about bad
It certainly gives the impression that there's a preference; it's like
saying The language of the feed SHOULD be English; there are lots of
options, and we don't require one, but it does call one out.
Why is this a normative requirement, and what does adding this sentence
bring to the spec?
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in
effect, is that the ID acts as a hash of entry's content, correct? If,
so, what value does it bring?
Pardon:
Any two versions of the same entry must use the same id, [which
On Friday, February 4, 2005, at 02:05 PM, Tim Bray wrote:
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any
two entries, ever.
I don't read it that way, although I understand how you might infer
that; there's too much wiggle
Baking this as a normative requirement -- even a SHOULD -- into a
standards-track RFC is a bad idea.
These formats are not the only interoperable formats on the planet, and
in fact they all have interop problems to some degree.
In five years, this requirement isn't going to make any sense.
If clients are told to ignore the order, and given only an updated timestamp,
there is no way to show most recent headlines...
At a single moment within a feedstream, sure... but the next time an
entry is added to that feed, I'll have no problem letting the user
know that this is new stuff.
When you talk about characters being the same or different, are you
saying in the entry, or in the id?
On Feb 4, 2005, at 2:18 PM, Graham wrote:
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in
effect, is that the ID acts as a
On Thu, 03 Feb 2005 19:56:32 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
For me, I'd like the comfort of knowing that a V1.0 feed will continue
to be valid with respect to future versions of the specifications, and
that tools written to consume V1.0 feeds will continue to work with
subsequent
On 4 Feb 2005, at 10:32 pm, Mark Nottingham wrote:
When you talk about characters being the same or different, are you
saying in the entry, or in the id?
Oh, right. The id. That would be clear if the things in brackets were
expanded (since same and different ids also need defining).
Graham
At 1:05 PM -0800 2/4/05, Tim Bray wrote:
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any
two entries, ever.
I don't read it that way, although I understand how you might infer
that; there's too much wiggle room in the current
Hmm. I'm thinking of profiles as fairly coarse-grained things; so
coarse-grained, it wouldn't make sense to mix-and-match them in a
single document (or, if you do, you either don't use a profile, or you
invent a new one).
I.e., does it make sense to mix a stock quote entry with a systems
Paul Hoffman wrote:
That means that you're not allowed to [use] the same atom:id in any
two entries, ever.
We have atom:modified in order to indicate that an instance is a
modified version of a previously published entry. The linkage between the
two instances of the entry is that they
It would make sense to mix syndication, archive, aggregation, etc.
In other words, some profiles would make sense to mix together.
Entry-scoped profile makes a LOT of sense.
@profile attribute on the feed level applies only to the feed and is
used to identify the collection(s) of metadata
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an
unchanging identifier which MUST be universally unique within Atom
Documents to the set of all versions and instantiations of the
resource that the construct's parent
Absolutely, there would be a core default profile defined in the Atom
syntax spec. @profiles=core syndication @profiles=core blog, etc.
On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
On Feb 4, 2005, at 3:13 PM, James M Snell wrote:
If a profile is indicated
Antone Roundy wrote:
3.5 Identity Constructs
An Identity construct is an element whose content conveys a permanent,
universally unique identifier for the resource (instantiated|described)
by the construct's parent element. An Atom Document MAY contain
multiple (revisions|versions) of the same
--On February 4, 2005 4:28:53 PM -0600 Roger B. [EMAIL PROTECTED] wrote:
If clients are told to ignore the order, and given only an updated timestamp,
there is no way to show most recent headlines...
At a single moment within a feedstream, sure... but the next time an
entry is added to that
Just a note; I'm planning to remove the Identity Construct from -06,
because it's only used in one place (the definition of atom:id).
Otherwise, this sounds like a reasonable start.
On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote:
On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an
unchanging identifier which MUST be universally unique within Atom
Documents to the set of all versions and
Clearly, I meant atom:updated not atom:modified... My apologies for the
slip.
bob wyman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray
Sent: Friday, February 04, 2005 7:11 PM
To: [EMAIL PROTECTED]
Cc: 'Mark Nottingham'; 'Paul
On 5 Feb 2005, at 12:09 am, Mark Nottingham wrote:
I was thinking of profiles only specifying:
- what metadata is required to be present
- optionally for each one that's required, the maximum number that
can be present
If profiles are constrained as such, they're pretty trivial to
compose;
On 3 Feb 2005, at 12:18 am, David Powell wrote:
{{{ 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.
}}}
First sentence no, but the second sentence
On 3 Feb 2005, at 9:36 pm, Graham wrote:
On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote:
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Yes. I like it too.
Just to clarify, I like it being there for
informational/statistics/debugging purposes. I don't see
Graham wrote:
-1
Putting everything in one group and requiring it to be first is useful,
and also adds consistency to head-in-entry, as evidenced by the
introduction of the feeder element. Also feeder is a horrible word.
And head doesn't suck? I struggle to type a sentence on the subject
Robert Sayre wrote:
HeadInEntry is trivial to do as an extension, so there's no
reason to leave it in.
There are a number of excellent reasons to leave it in!
1. Just about the only functional advantage that Atom has over RSS
is that HeadInEntry provides core support for
Any feedback on this guys? Curious to see what type of interest there is
here...
Kevin: Why would anyone want to fiddle around with HTML classes to
indicate comments when they can just publish/consume comment feeds? Or
did I misinterpret the purpose of the effort?
--
Roger Benningfield
68 matches
Mail list logo
