On 5/8/05 3:07 PM, James M Snell [EMAIL PROTECTED] wrote:
thr:in-reply-to id=urn:foo:1 type=application/atom+xml
src=http://www.example.com/atom; /
how about this instead
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
The intention of Simple Extension Elements is to provide a
simple class of extension that is part of the Atom model, and can
therefore be preserved end-to-end by implementions via publishing
clients, servers, databases, and aggregators.
We say that Simple Extension Elements are not language
* James M Snell [EMAIL PROTECTED] [2005-08-05 07:15]:
Does this work or do I need to be taken out and flogged again?
Absolutely that does work for me.
(Sorry for the curt reply – I am off to catch a plane in a few
minutes and won’t have ’net for a week. Tried to get this out
before I am gone.
Robert Sayre wrote:
I'll also note that this requirement has basically zero value for a
desktop aggragator. I have only written three or four Atom parsers,
but I think the approach that has the best mix of performance and
correctness is one where SAX events are treated as input events for a
On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote:
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
thread:idref=urn:foo:1 /
this way processors that have a basic understanding of what a
link is can
still do something useful.
On 5/8/05 9:55 PM, Tim Bray [EMAIL PROTECTED] wrote:
Uh, consider
link rel=ultimate-source-of-all-evil-STAY-AWAY
href=http://example.org/evil; /
What useful thing is there that software could sanely do, knowing
only that something is a link? -Tim
not knowing what that particular
On Aug 5, 2005, at 5:59 AM, David Powell wrote:
We say that Simple Extension Elements are not language sensitive,
but
They *are* affected by xml:base. xml:base establishes the base URI
for wherever it's in-scope, with a specific callout to RFC3986 for
the semantics. Anytime you see
* Tim Bray [EMAIL PROTECTED] [2005-08-05 14:05]:
Uh, anyone who's lazily concatenating strings is pretty soon
going to end up with a free ampersand or something worse in
their Atom feed. Right?
I think that’s a bit grand of a generalization.
It’s not hard to build XML by concatening strings,
Robert Sayre wrote:
On 8/5/05, Bill de hÓra [EMAIL PROTECTED] wrote:
If you're going to recommend ignoring it in practice, why not recommend
throwing it out? Why equivocate?
You keep saying equivocate, as if there were some hard-to-swallow
truth I'm avoiding.
I've said it twice; don't
A. Pagaltzis wrote:
I suggest simply the following: in 4.2.6 (The atom:id Element),
change
Its content MUST be an IRI, as defined by [RFC3987].
to read:
Its content MUST be an IRI, as defined by [RFC3987], and MUST
NOT contain any whitespace.
It doesn’t change anything, it just
On 5/8/05 7:48 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
thread:idref=urn:foo:1 /
this way processors that have a basic understanding of what a
link is can still do
In Section 2, paragraph 5,
Both kinds of Atom Documents are specified in terms of the XML
Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and
identified with the application/atom+xml media type. Atom
Documents MUST be well-formed XML. This specification does not
Robert Sayre wrote:
In Section 2, paragraph 5,
Both kinds of Atom Documents are specified in terms of the XML
Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and
identified with the application/atom+xml media type. Atom
Documents MUST be well-formed XML. This
On Fri, Aug 05, 2005 at 02:04:03PM -0400, Robert Sayre wrote:
1.) Atom processors MAY consider leading and trailing whitespace in
element and attribute values to be significant.
2.) In attribute values and elements containing text, leading and
trailing whitespace is considered significant.
14 matches
Mail list logo
