A few comments as I read the latest draft; apologies if I've missed
relevant discussion, a pointer would be greatly appreciated in that
case.
* 3.1 Text Constructs -- Since the atom:content no longer references
this construct, my preference would be to remove this section
altogether and make
On 30 Jan 2005, at 02:31, David Powell wrote:
[snip]
I meant, although:
XML --[XSLT]-- RDF/XML --[RDF/XML-parser]-- RDF-model
...is an ok reference implementation for demonstrating an RDF mapping,
the mapping should be defined in prose, because:
XML --[SAX]-- RDF-model
...would be a lot more
On 30 Jan 2005, at 7:48 am, Mark Nottingham wrote:
If so, why doesn't atom:author allow markup for the Person's name as
well? It would be odd, for example, to allow publishers to affect the
presentation of the title, but not the author's name.
Some people already use italics in their titles. Who
Robert, can you take a stab at updating section 1.2 for this Pace?
I'll also note that this example is not valid. It does not contain
either a summary or content element.
One thing to consider is to do like what was done in Atom 0.3 [1]:
provide both a minimal and maximal example.
- Sam Ruby
On 30/1/05 6:48 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
* 3.1 Text Constructs -- Since the atom:content no longer references
this construct, my preference would be to remove this section
altogether and make atom:title, atom:copyright, atom:summary,
atom:tagline and atom:info have simple
Robert Sayre wrote:
I think the mapping should be normatively defined w/ XSLT.
+1. I have no problem with defining the mapping in XSLT. Executable
specs are a wonderful idea.
cheers
Bill
Eric Scheid wrote:
On 30/1/05 6:48 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
* 4.15 The atom:content Element -- I strongly believe that more than
one atom:content should be allowed; there are use cases when there are
multiple representations of the item, and it is useful and necessary to
Robert Sayre wrote:
I made that mistake because the draft in front of me is organized quite
differently than the one in front of you.
It was unclear to me as well.
--
Anne van Kesteren
http://annevankesteren.nl/
On Sun, 30 Jan 2005 16:05:57 +, Bill de hÓra [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
I think the mapping should be normatively defined w/ XSLT.
+1. I have no problem with defining the mapping in XSLT. Executable
specs are a wonderful idea.
+1.
There still quite a margin for
* 4.15 The atom:content Element -- I strongly believe that more
than one atom:content should be allowed; there are use cases
when there are multiple representations of the item, and it is
useful and necessary to communicate this in the feed. I suggest
that multiple atom:content elements be
3.1.1
Thus, software MAY display it using normal text rendering techniques
such as proportional fonts, white-space collapsing, and justification.
This is horrible and doesn't really tell people at either end anything
new. It also needs to directly answer questions about the preservation
of
Robert Sayre wrote:
So I can not include MathML in the TITLE of my weblog? I do not see
why this restriction is necessary.
Nope. Can any aggregator display it? I wonder if Shrook users are
filling Graham's inbox with requests for MathML in their titles.
Addressed in a separate thread.
In Europe
Mark Nottingham wrote:
My gut feeling is that removing the markup from these elements will
make the spec much simpler and easier to implement, without
sacrificing many (if any) use cases. If I'm not aware of someone's use
case here, I'm sorry and I'd love to hear about it.
It doesn't really
Anne van Kesteren wrote:
* 4.15 The atom:content Element -- I strongly believe that more
than one atom:content should be allowed; there are use cases
when there are multiple representations of the item, and it is
useful and necessary to communicate this in the feed. I suggest
that multiple
3.5.1 Dereferencing Identity Constructs
The content of an Identity construct MAY be dereferencable (e.g. an
HTTP URI). However, processors MUST NOT assume it to be
dereferencable.
The first sentence doesn't say anything. The second is good but doesn't
go far enough.
The content of
This controversial text is still in:
Because of the risk of confusion between URIs that would be
equivalent if dereferenced, the following normalization strategy is
strongly encouraged when generating Identity constructs:
o Provide the scheme in lowercase characters.
o Provide the
On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote:
Here are some detailed obs on reading the latest draft.
Excellent, Bill, thanks.
** 1. Introduction
I don't think further discussion on motivation or principles is
needed; on that basis the [[more motivation/design principles]] memo
could be
Sam Ruby wrote:
...
I've reopened it minus the namespace restriction. I realize that Henri
is violently opposed to it, but his objection seem to reduce down to
cruft, and he seems to be in the minority. I see there to be a good
chance that rough consensus can be found on this pace.
...
For
Tim Bray wrote:
On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote:
** 4.15 The atom:content
[[[
atom:entry elements MUST contain zero or one atom:content elements.
]]]
proposal: I would like this loosened to zero or more (a Pace is
forthcoming). I have use cases to ship content about in Irish and
Sam Ruby wrote:
Robert Sayre wrote:
* 4.21 The atom:info Element -- If it's not considered meaningful
for processors, why does there need to be a standard element for it?
At the very least, some sort of information about its semantics
should be documented. My preference would be to drop it.
I suppose I should offer an alternative solution. Two scenarios were
given to justify canonicalization:
1) A publisher accidentally uses a different, though very similar, URI
for their id. They then apply the canonicalization rules and the error
is erased. This will only work if they remember
On Sun, 30 Jan 2005 18:43:18 +0100, Julian Reschke [EMAIL PROTECTED]
wrote:
For the record, I'm opposed to it, too.
Same here.
The spec is already saying this:
The content SHOULD be XHTML text and markup that could validly appear
directly within an xhtml:div element.
...so making it explicit
On 30 Jan 2005, at 5:24 pm, Sam Ruby wrote:
I've reopened it minus the namespace restriction. I realize that
Henri is violently opposed to it, but his objection seem to reduce
down to cruft, and he seems to be in the minority. I see there to
be a good chance that rough consensus can be found
Robert Sayre wrote:
Sam Ruby wrote:
Robert Sayre wrote:
* 4.21 The atom:info Element -- If it's not considered meaningful
for processors, why does there need to be a standard element for it?
At the very least, some sort of information about its semantics
should be documented. My preference
Sam Ruby wrote:
Then I am clearly confused.
At the moment, the feedvalidator would mark an atom feed as invalid if
it were served with the text/plan, application/rss+xml, or
application/rdf+xml media types. It accepts as valid text/xml (if the
feed is either ASCII or a charset is explictly
atom:head elements MUST NOT contain more than one atom:contributor element.
atom:entry elements MUST NOT contain more than one atom:contributor element.
they look like a copy/pasto, especially since above those lines there is
atomContributor*
e.
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
I'll also note that this example is not valid. It does not contain
either a summary or content element.
Hmm. How do I do a linkblog with this restriction?
Robert Sayre
On Jan 30, 2005, at 9:50 AM, Graham wrote:
2) An intermediary automatically c14nizes all URIs it processes. If
URIs come pre-c14nized from the publisher, this won't do any damage.
This is valid, but the problem is that these intermediaries are
currently imaginary.
I may be moving toward
On Jan 30, 2005, at 9:34 AM, Sam Ruby wrote:
== Abstract ==
Order the Element Definitions in the specification alphabetically.
+1 -Tim
On 31/1/05 4:43 AM, Julian Reschke [EMAIL PROTECTED] wrote:
The content SHOULD be XHTML text and markup that could validly appear
directly within an xhtml:div element.
...so making it explicit in the on-the-wire format seems to be
completely useless.
what's missing though is guidance that
Robert Sayre wrote:
Hmm. How do I do a linkblog with this restriction?
I believe a linkblog should always have atom:content which provides some
information on the reason why you posted the link or a comment on the
link or something similar.
--
Anne van Kesteren
http://annevankesteren.nl/
Graham wrote:
On 30 Jan 2005, at 5:24 pm, Sam Ruby wrote:
I've reopened it minus the namespace restriction. I realize that
Henri is violently opposed to it, but his objection seem to reduce
down to cruft, and he seems to be in the minority. I see there to
be a good chance that rough consensus
Tim Bray wrote:
On Jan 30, 2005, at 9:50 AM, Graham wrote:
2) An intermediary automatically c14nizes all URIs it processes. If
URIs come pre-c14nized from the publisher, this won't do any damage.
This is valid, but the problem is that these intermediaries are
currently imaginary.
I may be
Eric Scheid wrote:
On 31/1/05 4:43 AM, Julian Reschke [EMAIL PROTECTED] wrote:
The content SHOULD be XHTML text and markup that could validly appear
directly within an xhtml:div element.
...so making it explicit in the on-the-wire format seems to be
completely useless.
what's missing though is
Robert Sayre wrote:
How about this:
The only comparison method Atom Processors MUST support is
character-by-character comparison [RFC3986].
Atom Processors MAY perform additional scheme-specific comparisions.
If you do this:
http://Example.org/thing
http://example.org/thing
You cannot
Saturday, January 29, 2005, 11:13:51 AM, you wrote:
The RDF vocabulary was just constructed ad-hoc - like I said, it is
just a proof of concept. It uses a separate namespace to Atom and
defines some new terms, which solves any problems with non-unique
attributes.
That makes sense.
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 9:50 AM, Graham wrote:
2) An intermediary automatically c14nizes all URIs it processes. If
URIs come pre-c14nized from the publisher, this won't do any damage.
This is valid, but the problem is that these intermediaries are
currently
On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote:
That's an implementation issue that shouldn't affect the format.
Without any comment on the issue Julian was addressing, the above is
outrageous. Implementation issues are extremely material in discussion
of the format. Perhaps more material
Tim Bray wrote:
On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote:
That's an implementation issue that shouldn't affect the format.
Without any comment on the issue Julian was addressing, the above is
outrageous. Implementation issues are extremely material in discussion
of the format.
Paraphrasing Tim [1] I'm definitely -1 on losing 3.5.1, the
canonicalization warning is a hard-won compromise and seems to cause
no-one any pain.
We discussed this at extreme length, and no new arguments have been
brought forward. Rough consensus does not mean absolute consensus.
- Sam Ruby
Robert Sayre wrote:
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
It would be much easier to discuss the pace with an example.
I gather that a format-05 compatible feed, thus:
feed
entry
head.../head
Julian Reschke wrote:
Robert Sayre wrote:
Um, the spec doesn't say you can. If the comparision is done with
URI.equals(), it will be positive. If it is done with
String.equals(), it will be negative. That text is a refelection of
reality.
Sam Ruby wrote:
I am still confused.
Transforming an Atom feed into another format does not result in a
valid Atom feed.
Right, but it's useful for the tranformation.
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
If
On 30 Jan 2005, at 7:06 pm, Sam Ruby wrote:
Paraphrasing Tim [1] I'm definitely -1 on losing 3.5.1, the
canonicalization warning is a hard-won compromise and seems to cause
no-one any pain.
We discussed this at extreme length, and no new arguments have been
brought forward. Rough consensus
Robert Sayre wrote:
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
See the XML specification section F.2 [1]. It is quite possible for an
XML document to be valid if served with media type application/xml, but
for
Sam Ruby wrote:
Robert Sayre wrote:
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
It would be much easier to discuss the pace with an example.
I suspect that once people see some examples, objections will surface.
On Jan 30, 2005, at 19:06, Anne van Kesteren wrote:
In Europe there are lots of different languages. It does not make
sense to provide a feed based on language negotiation since feed
aggregators do not support that.
So how many European sites besides the EU have the resources to provide
Sam Ruby wrote:
Robert Sayre wrote:
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
See the XML specification section F.2 [1]. It is quite possible for
an XML document to be valid if served with media type
On Jan 30, 2005, at 9:07 AM, Robert Sayre wrote:
Mark Nottingham wrote:
My gut feeling is that removing the markup from these elements will
make the spec much simpler and easier to implement, without
sacrificing many (if any) use cases. If I'm not aware of someone's
use case here, I'm sorry
Hi,
first I'd like to thank the editors for the good work.
The issues were collected after reading the spec top-to-bottom, and
trying to produce an Atom-05 feed from an existing RSS-1.0 feed through
XSLT. Most of them are editorial.
Best regards,
Julian
-- snip --
05-C01, 1.2 Example
Mark Nottingham wrote:
...
+1
There may be good reasons for atom:host and atom:info to be there, but
they aren't really obvious by reading the spec alone.
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
On Jan 30, 2005, at 21:06, Julian Reschke wrote:
OK, I'll try to rephrase: changing the protocol format because one
implementor says that this makes it easier to implement IMHO is a bad
idea. Of course things look differently if this issue affects more
platforms/parsers/toolkits.
FWIW, one
Big +1!
On Jan 30, 2005, at 12:34 PM, Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
result
On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote:
The issues were collected after reading the spec top-to-bottom, and
trying to produce an Atom-05 feed from an existing RSS-1.0 feed
through XSLT. Most of them are editorial.
Good stuff, Julian.
If the value of type begins with text/ or ends
Tim Bray wrote:
On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote:
The issues were collected after reading the spec top-to-bottom, and
trying to produce an Atom-05 feed from an existing RSS-1.0 feed
through XSLT. Most of them are editorial.
Good stuff, Julian.
Thanks.
If the value of type
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
result in
Eric Scheid wrote:
atom:head elements MAY contain one or more atom:foo elements, so
long as they differ in the values they have for the attributes
atom:hreflang, xml:lang, or atom:type.
I'm not comfortable with either wording. Seems clumsy.
meta-question: should the spec even bother asserting
Julian Reschke wrote:
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
--On January 30, 2005 10:06:23 PM +0200 Henri Sivonen [EMAIL PROTECTED] wrote:
So how many European sites besides the EU have the resources to provide
translations of the *same* content in multiple languages at the same time?
Pretty common in Quebec. We see English and Spanish in the US from
Eric Scheid wrote:
On 31/1/05 6:17 AM, Robert Sayre [EMAIL PROTECTED] wrote:
Instances of Identity constructs can be compared to determine whether
an entry or feed is the same as one seen before. Processors MUST
compare Identity constructs on a character-by-character basis in a
case-sensitive
Julian Reschke wrote:
atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml;
Less: xhtml:em lt; /xhtml:em
/atomTitle
(hope I got these right).
This is not only right, but also a good example of why many people would
prefer to have another element so that they don't have to deal with
On 31/1/05 10:16 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I agree with you in principle, but I find the current text unrealistic.
It's just fodder for stupid arguments.
what? and Atom Processors MAY perform additional scheme-specific
comparisions won't lead to stupid arguments? Here's one
Eric Scheid wrote:
On 31/1/05 10:16 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I agree with you in principle, but I find the current text unrealistic.
It's just fodder for stupid arguments.
what? and Atom Processors MAY perform additional scheme-specific
comparisions won't lead to stupid
Tim Bray wrote:
On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote:
In 3.1.1 media types are not an option:
[[[
Note that MIME media types [RFC2045] are not acceptable values for the
type attribute.
]]]
I'm definitely -1 on losing 3.1.1, the text construct is a hard-won
compromise and seems to
Sam Ruby wrote:
Bill de hÓra wrote:
reason: we don't need to tell people what they can do with TEXT once
we tell them what it is.
Often times the use of MAY is advisory to the producer. This is one of
those cases: if you are expecting mono spaced fonts, you might want to
consider using either
On 30 Jan 2005, at 8:06 pm, Henri Sivonen wrote:
So how many European sites besides the EU have the resources to
provide translations of the *same* content in multiple languages at
the same time? How many of those can't provide multiple feed links and
really want to stuff everything in a single
Robert Sayre wrote:
Mark Nottingham wrote:
* 4.11 The atom:host Element -- I'm surprised to see this in an IETF
specification; people are going to make bad assumptions about the
content of this, and violate layering to populate it. At the VERY
least, I'd expect to see text in Security
Sam Ruby wrote:
Robert Sayre wrote:
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
It would be much easier to discuss the pace with an example.
I gather that a format-05 compatible feed, thus:
I suspect that once
On 30 Jan 2005, at 11:43 pm, Eric Scheid wrote:
what? and Atom Processors MAY perform additional scheme-specific
comparisions won't lead to stupid arguments?
Yeah, that's a horrible loose end to leave hanging.
The spec should (nay, MUST) mandate a method of comparing Identity
Constructs which will
--On January 30, 2005 12:34:42 PM -0500 Sam Ruby [EMAIL PROTECTED] wrote:
== Abstract ==
Order the Element Definitions in the specification alphabetically.
+1. Yes, please. It works fine for the HTTP spec.
wunder
--
Walter Underwood
Principal Architect, Verity
Robert Sayre wrote:
I suspect that once people see some examples, objections will surface.
I've included an example of each approach, so people can compare the two
methods. I have not positioned them as spec text. The spec requires more
examples no matter which approach the WG chooses.
Good
Graham wrote:
On 31 Jan 2005, at 12:16 am, Robert Sayre wrote:
Graham wrote:
Yeah, that's a horrible loose end to leave hanging.
No, it isn't. URI comparison is not our problem, and what our spec
says about it doesn't matter a bit.
Yes it is times one million. Ha ha I win et cetera
Defining
On Sun, 30 Jan 2005 17:57:57 +, Graham [EMAIL PROTECTED] wrote:
I'm in favor of it. My current parser doesn't let me pull out all
childen of element x in one go, so I have to step through in a really
hacky way. With this I can just grab the div.
You can't grab 'atom:content/*[1]' or something
On Sun, 30 Jan 2005 12:34:42 -0500, Sam Ruby [EMAIL PROTECTED]
wrote:
Order the Element Definitions in the specification alphabetically.
Sounds like a very good idea. +1.
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»
On Sun, 30 Jan 2005 14:06:49 -0500, Sam Ruby [EMAIL PROTECTED]
wrote:
We discussed this at extreme length, and no new arguments have been
brought forward. Rough consensus does not mean absolute consensus.
Thank you. We've discussed this too much already. Please let's leave this
horse; it's
Graham wrote:
On 31 Jan 2005, at 12:43 am, Robert Sayre wrote:
How about Make sure your id is unique from a character-by-character
perspective, but also unique in the face of scheme-specific
comparisons. That is, don't lean on scheme-specific comparisons to
match URIs, but they don't have to be
I'm not going to lie down in the road to get rid of atom:host, if there
are a lot of people that want it badly. However, it should be more
completely specified; i.e., some mention in security considerations,
and also, more information about the association.
Right now, it's just domain name or
On 31 Jan 2005, at 1:43 am, Tim Bray wrote:
Currently, the draft says *nothing* about xml:space (unless I'm
mis-using the search function). If you read the specification for
xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says
is that this is a message from the author to
OK. So, why is it necessary to standardise this element? Look at
http://www.mnot.net/test/atom.xml
which is the same feed, but with atom:info replaced by a 'foo' element.
Because the atom document has to reference the CSS anyway, it's
entirely reasonable to have the css specify what element
On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote:
which is the same feed, but with atom:info replaced by a 'foo' element.
Even better, you can drop foo and put the xhtml div as a direct child
of feed. Then use feed div as the selector.
And, if you use XSLT, it's also possible to do it all
At 5:11 PM + 1/30/05, Graham wrote:
3.5.1 Dereferencing Identity Constructs
The content of an Identity construct MAY be dereferencable (e.g. an
HTTP URI). However, processors MUST NOT assume it to be
dereferencable.
The first sentence doesn't say anything. The second is good but
Hey Bill,
Thanks for the detailed, well-justified and precise comments; this is a
very helpful format to submit them in (hint, hint). Some selective
feedback;
On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote:
Replace:
[[[
Note that the choice of any namespace prefix is arbitrary and not
On Jan 30, 2005, at 7:03 PM, Graham wrote:
On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote:
which is the same feed, but with atom:info replaced by a 'foo'
element.
Even better, you can drop foo and put the xhtml div as a direct child
of feed. Then use feed div as the selector.
Nice!
And, if
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
I'm +1 on this, but would be fine if the WG doesn't want to change.
Graham's wording is more useful to an implementer who wasn't on the
mailing list last year (or was on and skipped over the permathreads).
Ditto.
(Actually I think even having a
Paul Hoffman wrote:
At 5:11 PM + 1/30/05, Graham wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a version of the feed or entry may
On Sun, 30 Jan 2005 14:06:49 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
Paraphrasing Tim [1] I'm definitely -1 on losing 3.5.1, the
canonicalization warning is a hard-won compromise and seems to cause
no-one any pain.
We discussed this at extreme length, and no new arguments have been
Mark Nottingham wrote:
So, the relevant question seems to be whether any browsers do something
interesting with +xml media types;
No, the relevant question is whether +xml media types can be reliably
dispatched without any knowledge of a specific scheme. I don't know the
answer, but I do know
RFC 3023, Section 7:
This document recommends the use of a naming convention (a suffix of
'+xml') for identifying XML-based MIME media types, whatever their
particular content may represent. This allows the use of generic
XML
processors and technologies on a wide variety of different
On Sun, 30 Jan 2005 22:30:16 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
Paul Hoffman wrote:
At 5:11 PM + 1/30/05, Graham wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no
Joe Gregorio wrote:
I believe atom:host is the long lost descendent of atom:ipaddr, which came from
the problem I had implementing Atom on wiki, where the 'author' of an
entry can be difficult to pin down and the ip address may be the only
information available. If atom:host is what the
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a version of the feed or entry may be found.
I'm
On Jan 30, 2005, at 8:09 PM, Robert Sayre wrote:
Yay! Let's drop atom:host.
+1 oh yes please, I always thought it was lame-ass. -Tim
On 31/1/05 3:22 PM, Tim Bray [EMAIL PROTECTED] wrote:
When using atom:id to ascertain whether two Atom entries or feeds
are the same, such operations MUST be based only on the URI character
strings, and MUST NOT rely on dereferencing the URIs.
+1
Hey gang...
I'm fast approaching a 0.5 release of Jakarta FeedParser
http://jakarta.apache.org/commons/sandbox/feedparser/
And thought I'd solicit some feedback:
I'm also looking for some better unit tests for Atom 0.5. Hopefully
something under a more liberal license . The unit tests within
94 matches
Mail list logo
