Of course things look differently if this issue affects more
platforms/parsers/toolkits.
It does. I'm in a similar boat.
On the other hand, since I'm going to be forced to parse Atom 0.3
until the end of time, and some 0.3 feeds don't use the div, it really
doesn't make a difference to me.
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
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
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
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
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
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.
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
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 Jan 29, 2005, at 00:39, Sam Ruby wrote:
Henri Sivonen wrote:
On Jan 28, 2005, at 20:21, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations
must
be placed, but overall, I believe that the pace is a good idea.
I, for one, use gnu.xml.pipeline.NSFilter for ensuring
On Thu, 27 Jan 2005 13:30:40 -0700, Antone Roundy [EMAIL PROTECTED] wrote:
As far as the question of CSS and/or elements/tags everywhere, I'd
think that would be a matter for the security considerations section
(protecting against the Raging Platypus, for example). Whatever
restrictions we
Antone Roundy wrote:
On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote:
On Jan 27, 2005, at 22:30, Antone Roundy wrote:
I'm not in favor of mandating restrictions, because there are
probably legitimate uses for anything we might try to protect people
against.
The namespace div
Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Consumers don't want full web pages (complete with html head and titles)
as summaries, they want something that they can *insert* into a web
page.
On 28 Jan 2005, at 6:21 pm, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Yes.
and it succinctly provides a rather
good hint as to what child elements are valid.
Yes.
I would be OK with either
Julian Reschke wrote:
Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Consumers don't want full web pages (complete with html head and titles)
as summaries, they want something that they can
Given that common practice is to include this element, making it
mandatory makes things clearer to both people who are producing
consuming tools based on the spec, and people who are producing new
feeds based on copy and paste.
+1
--
Roger Benningfield
Henri Sivonen wrote:
On Jan 28, 2005, at 20:21, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace
correctness in my RSS feed.
On Jan 27, 2005, at 22:30, Antone Roundy wrote:
I'm not in favor of mandating restrictions, because there are probably
legitimate uses for anything we might try to protect people against.
The namespace div places restrictions on where namespace declarations
appear and, therefore, limits the
On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote:
On Jan 27, 2005, at 22:30, Antone Roundy wrote:
I'm not in favor of mandating restrictions, because there are
probably legitimate uses for anything we might try to protect people
against.
The namespace div places restrictions on
21 matches
Mail list logo