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 atom:head
On Thu, 3 Feb 2005 23:39:51 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote:
>
> On Thursday, February 3, 2005, at 11:07 PM, James Snell wrote:
> > Figured I would formalize what I've been evangelizing the past couple
> > of days.
> >
> > http://www.intertwingly.net/wiki/pie/PaceAggregationInSepa
On Fri, 04 Feb 2005 02:51:28 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
> 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 allow
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 interest
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
[...]
Wh
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.
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 abou
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.
hmmm ... i
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 ev
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 feeds
> 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 c
Bob Wyman wrote:
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!
I totally disagree! But you can keep it! (see other mail :)
1. Just about the only functional "advantage" that At
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
On Feb 3, 2005, at 6:37 PM, Tim Bray wrote:
On reflection, I am growing very negative on almost all of the
"Organization" Paces, including FeedRecursive, PaceEntriesElement,
PaceCollection. Here's why: they represent to increase the level of
abstraction in Atom, and in my experience, when the g
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
Mostly for the sake of completeness...
http://www.intertwingly.net/wiki/pie/PaceHeadless
which takes the recursion out of PaceFeedRecursive, though I still
prefer that one because it doesn't lose hierarchy. PaceHeadless
also adds an atom:feeder child element of atom:entry, so that the
functional
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 towar
http://www.intertwingly.net/wiki/pie/PaceAggregationDocument2
Simplified version of PaceAggregationDocument: adds an
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 gauge.
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
http://nwals
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 regex
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
coun
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 th
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
Roy T. Fielding wrote:
Entry is a data model that easily fits the XML format, assuming
we ignore (for the moment) that entries and entry summaries are
actually quite different. It would be nice if atom would define
a distinct data model for entry first, before it got tied up in
the details of how
/ 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
Norman Walsh wrote:
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 mi
/ 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.
*s
At 8:55 PM -0800 2/3/05, Mark Nottingham wrote:
Walter brings up an important point; has, or when will, the drafts
be compared to the requirements in the charter?
I have compared the format draft to the charter and it meets the
requirements, at least in my eyes (which are the eyes of a protocol
At 11:48 PM -0800 2/3/05, James Snell 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.
What if an entry is part of many feeds
Julian Reschke wrote:
...
2. RFC 3339 allows the replacement of the 'T' with a space which
xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC
3339 isn't actually a "profile of ISO 8601" as it claims].
As far as I can tell, ISO 8601 allows this.
And anyway, what RFC3339 says is:
--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 Constructs in
>
/ 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 C
--On February 4, 2005 6:46:33 PM +0100 Julian Reschke <[EMAIL PROTECTED]> wrote:
>> Also, we have an unresolved issue with historic Livejournal entries,
>> which do not have timezones. XML Schema explains exactly how to
>
> So what does it recommend?
>
>> handle those. We can have a SHOULD for
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 al
On Feb 4, 2005, at 8:37 AM, Robert Sayre 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 Constructs in
terms of W3C XML Schema Part 2 than RFC 333
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 co
On Friday, February 4, 2005, at 09:16 AM, Antone Roundy wrote:
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
--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 to in the Pace?
That would be bogus a rule. How does it
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:dateTi
Walter Underwood wrote:
--On February 4, 2005 6:46:33 PM +0100 Julian Reschke <[EMAIL PROTECTED]> wrote:
Also, we have an unresolved issue with historic Livejournal entries,
which do not have timezones. XML Schema explains exactly how to
So what does it recommend?
handle those. We can have a SHOU
Robert Sayre wrote:
> Now that you've written PaceRemoveHeadElement [or, PaceHeadless]...
>(Note to Bob: it still does what you want), I think that is what
> will probably happen.
As long as we can put the feed metadata into an Entry document or
instance of an entry I'm happy. I don't care
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* date. So I have
no
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 cha
Paul Hoffman wrote:
> In specific, "a complete archive of all entries in a feed" is well
> taken care of by our current format; it's just not explicitly called
> "an archive". The fact that our IDs are unique over all time means an
> archive of all entries that were ever in the main feed is just a
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 l
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* dat
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 Identit
* 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 con
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" El
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 entr
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 disti
Graham, the issue here is that the spec can be interpreted in a number
of ways, which is not good. You seem to agree with that below, correct?
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
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 serv
Tim Bray wrote:
On Feb 4, 2005, at 8:37 AM, 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 everyone
else will do.
For
--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 th
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
the
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 days
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?
On Feb 4, 2005, at 2:04 PM, Graham wrote:
On 4 Feb 2005, at 9:10 pm, Mark Nottingham wrote:
Separately, there's the issue of wha
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 im
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 Friday, February 4, 2005, at 02:00 PM, 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 lite
Mark Nottingham wrote:
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 sentenc
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
requi
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 roo
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.
I've
> 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.
On Friday, February 4, 2005, at 03:04 PM, Robert Sayre wrote:
Sophisticated implementations can assert common ancestry with an
extension element.
Could you elaborate a little on this. If we forbid putting two
revisions of the same entry into a single document (unless you change
the ID between
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
> subseque
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 t
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
mo
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
Antone Roundy wrote:
On Friday, February 4, 2005, at 03:04 PM, Robert Sayre wrote:
Sophisticated implementations can assert common ancestry with an
extension element.
Could you elaborate a little on this. If we forbid putting two
revisions of the same entry into a single document (unless you ch
OK, so it sounds like this is just down to the slippery topic of
defining what an entry is, or coming up with the appropriate weasel
words the have the same effect without doing it.
I don't envy the editors on this one.
Uh-oh...
On Feb 4, 2005, at 1:26 PM, Paul Hoffman wrote:
At 1:05 PM -0800
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 el
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 ins
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
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 a
True, but I don't think it needs to be anything all that complicated. A
profile defines what metadata elements [must|must not|may|may
not|should|should not] be found in that particular entry/feed. What
more beyond that would be required?
- James M Snell
Mark Nottingham wrote:
but then you get
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:
"
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;
if we allow them to say what *isn't* allowed to be t
On Feb 4, 2005, at 2:43 PM, Bob Wyman wrote:
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.
We do? I don't think s
Any feedback on this guys? Curious to see what type of interest there
is here...
http://wiki.apache.org/jakarta-commons/FeedParser_2fOpenComments
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.
Rojo is
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 instantiation
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 Ho
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; i
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 s
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
-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.
Graham
smime.p7s
Description: S/MIME cryptographic signature
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
wit
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 ag
> 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
Jou
99 matches
Mail list logo
