Re: PaceXhtmlNamespaceDiv posted

[Roger B.]

> 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. I'm gonna be looping over and
xmlChildren array no matter what.

Requiring the div could certainly make life easier for those who are
going to restrict parsing to Atom 1.0, though.

--
Roger Benningfield
http://admin.support.journurl.com/

Re: PaceXhtmlNamespaceDiv posted

[Asbjørn Ulsberg]

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 similar?
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: PaceXhtmlNamespaceDiv posted

[Henri Sivonen]

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 could let WebCore see the Atom Text construct element without 
harm. So if a single container is needed, the Text construct itself is 
the obvious container.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

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.  Perhaps more material than anything else. -Tim
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.

So yes, more information is needed.
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Tim Bray]

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 than anything else. -Tim

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

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 guidance that the "XHTML text and markup" needs to
be in the xhtml namespace, and not just plonked in there by a crude
template-style publisher.
that is, it needs to be clear from the spec that this is wrong:
Here is a bold statement
...at least it's not what the producer probably intends.
Given the mass of content which is published via crude string concatenation
template driven CMS products, this is something we need to address. As it is
at the moment, a naïve reading of the spec suggests that the above atom XML
is valid because the  element *does* contain "XHTML text and markup
that could validly appear directly within an xhtml:div element".
By the way, are we assuming that the reader is meant to assume that the
namespace prefix "xhtml" has been bound to the xhtml namespace?
These are good points, so this should be clarified (independently of 
whether we require div or not).

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

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 can be found on this pace.

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.
That's an implementation issue that shouldn't affect the format.
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Eric Scheid]

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 the "XHTML text and markup" needs to
be in the xhtml namespace, and not just plonked in there by a crude
template-style publisher.

that is, it needs to be clear from the spec that this is wrong:

Here is a bold statement

Given the mass of content which is published via crude string concatenation
template driven CMS products, this is something we need to address. As it is
at the moment, a naïve reading of the spec suggests that the above atom XML
is valid because the  element *does* contain "XHTML text and markup
that could validly appear directly within an xhtml:div element".

By the way, are we assuming that the reader is meant to assume that the
namespace prefix "xhtml" has been bound to the xhtml namespace?

e.

Re: PaceXhtmlNamespaceDiv posted

[Graham]

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 this pace.
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.

+1
Graham

smime.p7s
Description: S/MIME cryptographic signature

Re: PaceXhtmlNamespaceDiv posted

[Asbjørn Ulsberg]

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 in the on-the-wire format seems to be  
completely useless.
Indeed.
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

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 the record, I'm opposed to it, too. 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 in the on-the-wire format seems to be 
completely useless.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Sam Ruby]

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 places restrictions on where namespace declarations 
appear and, therefore, limits the legitimate use of serializers that 
take care of namespace declarations.

-1 for the pace, still.
Okay, this one's obviously dead.  Let's just make sure we have examples 
that make how all these things work clear.
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.

- Sam Ruby

Re: PaceXhtmlNamespaceDiv posted

[Henri Sivonen]

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 the namespace 
correctness in my RSS feed.  If the current spec language stands, I 
will be able to trivially add Atom output with type='XHTML' by doing 
a DOM to DOM copy (without div cruft) and letting the serialization 
phase sort out the namespace declarations for me. If this pace was 
accepted, I'd have to break the namespace abstraction and fiddle with 
the namespace declaration details to meet additional requirements 
that are unnecessary as per "Namespaces in XML".
Are you saying that you can do a DOM to DOM copy to place a series of 
elements inside the following:

  atom:feed/atom:entry/atom:content
But you would find it extraordinarily difficult to place the exact 
same series of elements inside the following:

  atom:feed/atom:entry/atom:content/xhtml:div
If so, I would find such an assertion to be hard to accept.
No, of course those two are equally easy. The latter is just crufty.
My point was that having the namespace declarations appear in a 
particular choice of syntactic sugar would hinder the use of an 
automatic namespace declaration manager.

If element names are prefixed, string concatenation is not an option 
anyway.
Which is why it would be harmful to imply that a string concatenation 
implementation was ok.

If element names are not prefixed (as is the case with the overwheming 
majority of existing HTML), adding a div is exactly what makes things 
safe for simple string concatenators.
I don't see how it makes string concatenation easier that concatenating 
the contents of the Text construct otherwise. But since it doesn't work 
in all cases, it certainly should not be specced for. Speccing for tag 
soup concatenation would just encourage implementors to do tag soup 
concatenation. Wasn't the whole reason for the existence of 
type='XHTML' to provide something that is more sound from the XML point 
of view than entity-encoded HTML?

And no, a div does not give any useful hint to the ViewSourceClan, 
because it is an anything goes element.

I am sorry I brought up the subject of Text constructs. How about 
withdrawing both PaceTypeTextRedundant and PaceXhtmlNamespaceDiv and 
sticking to what draft-ietf-atompub-format-04 said?

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv posted

[Sam Ruby]

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.  If the current spec language stands, I will 
be able to trivially add Atom output with type='XHTML' by doing a DOM to 
DOM copy (without div cruft) and letting the serialization phase sort 
out the namespace declarations for me. If this pace was accepted, I'd 
have to break the namespace abstraction and fiddle with the namespace 
declaration details to meet additional requirements that are unnecessary 
as per "Namespaces in XML".
Are you saying that you can do a DOM to DOM copy to place a series of 
elements inside the following:

  atom:feed/atom:entry/atom:content
But you would find it extraordinarily difficult to place the exact same 
series of elements inside the following:

  atom:feed/atom:entry/atom:content/xhtml:div
If so, I would find such an assertion to be hard to accept.
(Similar considerations apply to GenX if the user chooses to leave 
namespace declaration management to the serializer.)

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.
Insertion is possible without a div as well if the insertion is 
implemented using proper XML tools and the target of the insertion is a 
real XHTML skeleton and not a tag soup skeleton and the resulting 
document is sent down the XML code path of Gecko, WebCore, Presto, etc. 
For Trident, the aggregator would have to serialize to HTML, which is 
pretty easy.

On the other hand, a div does not make Atom safe for tag soup 
concatenators, because the element names may be prefixed.
If element names are prefixed, string concatenation is not an option anyway.
If element names are not prefixed (as is the case with the overwheming 
majority of existing HTML), adding a div is exactly what makes things 
safe for simple string concatenators.

- Sam Ruby

Re: PaceXhtmlNamespaceDiv posted

[Henri Sivonen]

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.  If the current spec language stands, I 
will be able to trivially add Atom output with type='XHTML' by doing a 
DOM to DOM copy (without div cruft) and letting the serialization phase 
sort out the namespace declarations for me. If this pace was accepted, 
I'd have to break the namespace abstraction and fiddle with the 
namespace declaration details to meet additional requirements that are 
unnecessary as per "Namespaces in XML".

(Similar considerations apply to GenX if the user chooses to leave 
namespace declaration management to the serializer.)

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.
Insertion is possible without a div as well if the insertion is 
implemented using proper XML tools and the target of the insertion is a 
real XHTML skeleton and not a tag soup skeleton and the resulting 
document is sent down the XML code path of Gecko, WebCore, Presto, etc. 
For Trident, the aggregator would have to serialize to HTML, which is 
pretty easy.

On the other hand, a div does not make Atom safe for tag soup 
concatenators, because the element names may be prefixed.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv posted

[Roger B.]

> 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

Re: PaceXhtmlNamespaceDiv posted

[Sam Ruby]

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 *insert* into a web
page.  Requiring a div element addresses a number of needs - it makes it
easier to get the namespace right, and it succinctly provides a rather
good hint as to what child elements are valid.
That's what the spec already says, doesn't it? -> 
 
There are cases where explicit is better than implicit.
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.

- Sam Ruby

Re: PaceXhtmlNamespaceDiv posted

[Graham]

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 keeping the definition of type='XHTML' 
consistent (there are other types available,
after all)
Yes.
or requiring a summary element to be present if the first
child element of atom:content with type='XHTML' is not an xhtml:div.
Ew.
Graham

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

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.  Requiring a div element addresses a number of needs - it makes it
easier to get the namespace right, and it succinctly provides a rather
good hint as to what child elements are valid.
That's what the spec already says, doesn't it? -> 


...
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Sam Ruby]

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 places restrictions on where namespace declarations 
appear and, therefore, limits the legitimate use of serializers that 
take care of namespace declarations.

-1 for the pace, still.
Okay, this one's obviously dead.  Let's just make sure we have examples 
that make how all these things work clear.
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.  Requiring a div element addresses a number of needs - it makes it
easier to get the namespace right, and it succinctly provides a rather
good hint as to what child elements are valid.
On content, the situation is a bit different - the content need not be
displayable, after all.  I would be OK with either keeping the
definition of type='XHTML' consistent (there are other types available,
after all) or requiring a summary element to be present if the first
child element of atom:content with type='XHTML' is not an xhtml:div.
- Sam Ruby

Re: PaceXhtmlNamespaceDiv posted

[Joe Gregorio]

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 may pronounce, consumers will still have to include
> code to protect against abuses.  And these issues apply equally to HTML
> as to XHTML.
> 
> I'm not in favor of mandating restrictions, because there are probably
> legitimate uses for anything we might try to protect people against.

+1, and the same goes for 'id', just leave it as an item for the security
considerations.

-joe

-- 
Joe Gregoriohttp://bitworking.org

Re: PaceXhtmlNamespaceDiv posted

[Antone Roundy]

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 where namespace declarations 
appear and, therefore, limits the legitimate use of serializers that 
take care of namespace declarations.

-1 for the pace, still.
Okay, this one's obviously dead.  Let's just make sure we have examples 
that make how all these things work clear.

Re: PaceXhtmlNamespaceDiv posted

[Henri Sivonen]

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 legitimate use of serializers that 
take care of namespace declarations.

-1 for the pace, still.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv posted

[Antone Roundy]

On Thursday, January 27, 2005, at 12:32  PM, Antone Roundy wrote:
If the value of "type" is "XHTML", the content of the Text construct 
MUST be a single xhtml:div element which MUST declare the XHTML 
namespace.
Would it be too picky to assert that this language doesn't allow 
whitespace before and after the div?  Do we WANT to forbid such 
whitespace?  If not, does the language need to be adjusted?

Re: PaceXhtmlNamespaceDiv posted

[Antone Roundy]

On Thursday, January 27, 2005, at 01:32  PM, Anne van Kesteren wrote:
Antone Roundy wrote:
If the value of "type" is "XHTML", the content of the Text
construct MUST be a single xhtml:div element which MUST declare
the XHTML namespace. The xhtml:div MAY contain XHTML
s/MAY/SHOULD/, surely?
Yes, but getting the wording precise without being too verbose is a 
little tricky. The reason I wrote MAY is that it could conceivably be
empty, or it could contain just text OR markup.  Here would be the 
bullet proof but slightly wordy version:
The content of the xhtml:div, if any, MUST be XHTML text and/or
markup that could validly appear directly within an xhtml:div
element.
Any better ideas, anyone?
The content of the xhtml:div element MUST be XHTML or empty.
TEXT and other things are also inside of the XHTML thing. By the way,
does this exclude MathML and other things that can be easy mixed with 
XHTML?

How about if we remove "XHTML", changing it to this:
The content of the xhtml:div, if any, MUST be text and/or
markup that could validly appear directly within an xhtml:div
element.
Thus, if MathML can be mixed in with XHTML in a div, it's allowed.
Perhaps "directly" could be removed too.

Re: PaceXhtmlNamespaceDiv posted

[Anne van Kesteren]

Antone Roundy wrote:
If the value of "type" is "XHTML", the content of the Text
construct MUST be a single xhtml:div element which MUST declare
the XHTML namespace. The xhtml:div MAY contain XHTML
s/MAY/SHOULD/, surely?
Yes, but getting the wording precise without being too verbose is a 
little tricky. The reason I wrote MAY is that it could conceivably be
empty, or it could contain just text OR markup.  Here would be the 
bullet proof but slightly wordy version:

The content of the xhtml:div, if any, MUST be XHTML text and/or
markup that could validly appear directly within an xhtml:div
element.
Any better ideas, anyone?
The content of the xhtml:div element MUST be XHTML or empty.
TEXT and other things are also inside of the XHTML thing. By the way,
does this exclude MathML and other things that can be easy mixed with XHTML?
--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv posted

[Antone Roundy]

On Thursday, January 27, 2005, at 12:45  PM, Anne van Kesteren wrote:
http://www.w3.org/1999/xhtml"; 
style="color:#03c;">This is XHTML content.
Can't we forbid the STYLE attribute? Or define a subset of allowed
elements/attribute?
On this mandatory div, or everywhere?  If we forbid it on this div, 
we'll end up with:

http://www.w3.org/1999/xhtml";>This is XHTML content. 

Is that preferable?
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 may pronounce, consumers will still have to include 
code to protect against abuses.  And these issues apply equally to HTML 
as to XHTML.

I'm not in favor of mandating restrictions, because there are probably 
legitimate uses for anything we might try to protect people against.

Re: PaceXhtmlNamespaceDiv posted

[Antone Roundy]

On Thursday, January 27, 2005, at 12:58  PM, Tim Bray wrote:
On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote:
If the value of "type" is "XHTML", the content of the Text construct 
MUST be a single xhtml:div element which MUST declare the XHTML 
namespace. The xhtml:div MAY contain XHTML
s/MAY/SHOULD/, surely?
 text and markup that could validly appear directly within an 
xhtml:div element. Receiving software which displays the content MAY 
use the markup to aid in displaying it. Escaped markup is interpreted 
as a text representation of markup, and MUST NOT be interpreted as 
markup itself.

Yes, but getting the wording precise without being too verbose is a 
little tricky. The reason I wrote MAY is that it could conceivably be 
empty, or it could contain just text OR markup.  Here would be the 
bullet proof but slightly wordy version:

The content of the xhtml:div, if any, MUST be XHTML text and/or markup 
that could validly appear directly within an xhtml:div element.

Any better ideas, anyone?

Re: PaceXhtmlNamespaceDiv posted

[Antone Roundy]

On Thursday, January 27, 2005, at 12:45  PM, Anne van Kesteren wrote:
http://www.w3.org/1999/xhtml";>This is 
XHTML content.
This DIV element != xhtml:div so this example would be invalid, right?
Oops.  Fixed it.

Re: PaceXhtmlNamespaceDiv posted

[Tim Bray]

On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote:
If the value of "type" is "XHTML", the content of the Text construct 
MUST be a single xhtml:div element which MUST declare the XHTML 
namespace. The xhtml:div MAY contain XHTML
s/MAY/SHOULD/, surely?
 text and markup that could validly appear directly within an 
xhtml:div element. Receiving software which displays the content MAY 
use the markup to aid in displaying it. Escaped markup is interpreted 
as a text representation of markup, and MUST NOT be interpreted as 
markup itself.

Re: PaceXhtmlNamespaceDiv posted

[Anne van Kesteren]

Antone Roundy wrote:
http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
If the value of "type" is "XHTML", the content of the Text construct
MUST be a single xhtml:div element which MUST declare the XHTML 
namespace. The xhtml:div MAY contain XHTML text and markup that could
validly appear directly within an xhtml:div element. Receiving
software which displays the content MAY use the markup to aid in
displaying it. Escaped markup is interpreted as a text representation
of markup, and MUST NOT be interpreted as markup itself.
Namespace prefixes are still allowed?

Examples:
http://www.w3.org/1999/xhtml"; 
style="color:#03c;">This is XHTML content.
Can't we forbid the STYLE attribute? Or define a subset of allowed
elements/attribute?
It would help a bit if we declare what XHTML DTD we are following. It
would suck that when XHTML 2.0 is released we allow people to enter it
directly without updating the Atom specification.

http://www.w3.org/1999/xhtml";>This is 
XHTML content.
This DIV element != xhtml:div so this example would be invalid, right?
--
 Anne van Kesteren
 

PaceXhtmlNamespaceDiv posted

[Antone Roundy]

http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
Abstract
When a Text construct or atom:content's type is "XHTML", require it to 
have a single xhtml:div as a child, and require that div to declare the 
XHTML namespace.

Status
Open
Rationale
   1. Given that even we often forget when writing examples to declare 
the XHTML namespace for XHTML text constructs and content elements, it 
seems likely that people producing actual feeds will forget to do so 
unless the requirement to do so is stated prominently and unambiguously.
   2. Mandating a specific method of declaring the XHTML namespace will 
ensure uniformity between feeds.

Proposal
Replace the paragraph on XHTML in section 3.1.1 of 
draft-ietf-atompub-format-04.txt with the following:

If the value of "type" is "XHTML", the content of the Text construct 
MUST be a single xhtml:div element which MUST declare the XHTML 
namespace. The xhtml:div MAY contain XHTML text and markup that could 
validly appear directly within an xhtml:div element. Receiving software 
which displays the content MAY use the markup to aid in displaying it. 
Escaped markup is interpreted as a text representation of markup, and 
MUST NOT be interpreted as markup itself.

Examples:
http://www.w3.org/1999/xhtml"; 
style="color:#03c;">This is XHTML content.

http://www.w3.org/1999/xhtml";>This is 
XHTML content.

Replace the text of item 3 in section 5.12.3 with the same paragraph, 
and put the examples (and examples of the other types) after the list, 
with "summary" changed to "content".

Impacts
This is the common method of including XHTML content in existing Atom 
feeds, so the impact on existing implementations should be minimal to 
nil.