Subject: PaceXhtmlNamespaceDiv posted

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 12:32:13 -0700

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:

<summary type="XHTML"><div xmlns="http://www.w3.org/1999/xhtml" 
style="color:#03c;">This is <b>XHTML</b> content.</div></summary>

<summary type="XHTML"><div 
xmlns:xhtml="http://www.w3.org/1999/xhtml">This is 
<xhtml:b>XHTML</xhtml:b> content.</div></summary>

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.

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 27 Jan 2005 20:45:40 +0100

Antone Roundy wrote:
> 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?

> style="color:#03c;">This is <b>XHTML</b> content.</div></summary>

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.

> <xhtml:b>XHTML</xhtml:b> content.</div></summary>

This DIV element != xhtml:div so this example would be invalid, right?

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Tim Bray <[email-masked]>
Date: Thu, 27 Jan 2005 11:58:56 -0800

On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote:

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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 13:09:30 -0700

> This DIV element != xhtml:div so this example would be invalid, right?
Oops.  Fixed it.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 13:17:11 -0700

>> as a text representation of markup, and MUST NOT be interpreted as 
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?

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 13:30:40 -0700

> Can't we forbid the STYLE attribute? Or define a subset of allowed
On this mandatory div, or everywhere?  If we forbid it on this div, 
we'll end up with:

<summary type="XHTML"><div xmlns="http://www.w3.org/1999/xhtml"><div 
style="color:#03c;">This is <b>XHTML</b> content. </div></div></summary>

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.

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 27 Jan 2005 21:32:28 +0100

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?
> 
> 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.
> 

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?

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 13:39:56 -0700

> does this exclude MathML and other things that can be easy mixed with 
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.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 13:37:11 -0700

On Thursday, January 27, 2005, at 12:32  PM, Antone Roundy wrote:
> 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?

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 28 Jan 2005 07:38:30 +0200

> 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-masked]
http://iki.fi/hsivonen/

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 22:46:06 -0700

On Thursday, January 27, 2005, at 10:38  PM, Henri Sivonen wrote:
>> I'm not in favor of mandating restrictions, because there are 
>> probably legitimate uses for anything we might try to protect people 
>> against.
>
Okay, this one's obviously dead.  Let's just make sure we have examples 
that make how all these things work clear.

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 28 Jan 2005 13:03:34 -0500

> 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 Gregorio        http://bitworking.org

---

From: Sam Ruby <[email-masked]>
Date: Fri, 28 Jan 2005 13:21:58 -0500

> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jan 2005 19:40:37 +0100

> good hint as to what child elements are valid.

That's what the spec already says, doesn't it? -> 
<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1.p.6>

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Graham <[email-masked]>
Date: Fri, 28 Jan 2005 18:58:32 +0000

> be placed, but overall, I believe that the pace is a good idea.

Yes.

>  and it succinctly provides a rather

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

Ew.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Fri, 28 Jan 2005 14:15:56 -0500

> <http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1.p.6> 

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

---

From: "Roger B." <[email-masked]>
Date: Fri, 28 Jan 2005 13:22:14 -0600

> feeds based on copy and paste.

+1

--
Roger Benningfield

---

From: Henri Sivonen <[email-masked]>
Date: Sat, 29 Jan 2005 00:12:16 +0200

> 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.)

> 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-masked]
http://iki.fi/hsivonen/

---

From: Sam Ruby <[email-masked]>
Date: Fri, 28 Jan 2005 17:39:01 -0500

Henri Sivonen wrote:
> 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.

> 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

---

From: Henri Sivonen <[email-masked]>
Date: Sat, 29 Jan 2005 09:52:54 +0200

On Jan 29, 2005, at 00:39, Sam Ruby wrote:

>> 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".
>
> But you would find it extraordinarily difficult to place the exact 
> same series of elements inside the following:
>

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 

Which is why it would be harmful to imply that a string concatenation 
implementation was ok.

> 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-masked]
http://iki.fi/hsivonen/

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 12:24:10 -0500

> 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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 30 Jan 2005 19:01:29 +0100

On Sun, 30 Jan 2005 18:43:18 +0100, Julian Reschke <[email-masked]>  
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»

---

From: Graham <[email-masked]>
Date: Sun, 30 Jan 2005 17:57:57 +0000

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

---

From: Eric Scheid <[email-masked]>
Date: Mon, 31 Jan 2005 05:23:21 +1100

> ...so making it explicit in the on-the-wire format seems to be

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:

    <content type="XHTML">Here is a <b>bold statement</b></content>

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 <content> 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.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jan 2005 18:43:18 +0100

> 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:

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jan 2005 19:35:18 +0100

> hacky way. With this I can just grab the div.

That's an implementation issue that shouldn't affect the format.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jan 2005 19:37:05 +0100

>     <content type="XHTML">Here is a <b>bold statement</b></content>

...at least it's not what the producer probably intends.

> 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

---

From: Tim Bray <[email-masked]>
Date: Sun, 30 Jan 2005 11:00:31 -0800

> 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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jan 2005 20:06:34 +0100

> 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

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 30 Jan 2005 22:36:41 +0200

> 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-masked]
http://iki.fi/hsivonen/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 31 Jan 2005 02:03:59 +0100

> hacky way. With this I can just grab the div.

You can't grab 'atom:content/*[1]' or something similar?