Subject: PaceXmlContentWrapper

From: Antone Roundy <[email-masked]>
Date: Tue, 19 Apr 2005 14:18:23 -0600

It may be too late, but either way, I'd like to get this into concrete 
form.  Does anyone think this is worse than requiring the xhtml:div?  
Better?

http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper

== Abstract ==

Replace the requirement for an xhtml:div wrapper for 
content[type="xhmtl"] with an optional attribute to indicate whether 
the top level element of XML content is a disposable wrapper or part of 
the content.

== Rationale ==

  * When embedding XML in XML, the inner XML content is often wrapped in 
an extra element from the content's namespace in order to provide a 
place to declare the inner XML's namespace (whether making it the 
default namespace or not).
  * Unless there is a method to specify whether such a wrapper element 
has been added to the inner content, the status of the outer element of 
the inner content is ambiguous. Is it part of the content, or not?
  * In requiring a wrapper div for XHTML content, the current draft 
resolves this question only for XHTML content.
  * ...and it resolves it by a method to which a number of people object.
  * This proposal creates an alternative method which would work for all 
XML content types, and which only requires adding to the feed when 
action (disposing of the wrapper, or otherwise recognizing that it's 
not part of the content) is required.

== Proposal ==

Add the following under section 3.1:

3.1.2 The "wrapper" Attribute

  Text constructs MAY have a "wrapper" attribute if the value of the 
"type" attribute is "xhtml". When present, the value MUST be one of 
"none" or "dispose". If the "wrapper" attribute is not provided, Atom 
Processors MUST behave as though it were present with a value of "none".

  If the value is "dispose", the Text construct MUST have a single 
element child, which Atom Processors MUST treat as a disposable wrapper 
for the XHTML content, and not as part of the content itself. If the 
value is "none", Atom Processors MUST NOT treat any element children of 
the Text construct as disposable wrapper elements.

Add the following under section 4.1.3:

4.1.3.2 The "wrapper" Attribute

  The atom:content element MAY have a "wrapper" attribute if the value 
of the "type" attribute is "xhtml" or a MIME media type ending in 
"/xml" or "+xml". When present, the value MUST be one of "none" or 
"dispose". If the "wrapper" attribute is not provided, Atom Processors 
MUST behave as though it were present with a value of "none".

  If the value is "dispose", atom:content MUST have a single element 
child, which Atom Processors MUST treat as a disposable wrapper for the 
content, and not as part of the content itself. If the value is "none", 
Atom Processors MUST NOT treat any element children of atom:content as 
disposable wrapper elements.

Remove the requirement for an XHTML div from sections 3.1.1.3 and 
4.1.3.3, item 3, and adjust the example feeds as appropriate.

== Impacts ==

Publishing tools now using wrapper elements would need to add an 
attribute to the containing elements, and consumers would need to key 
their treatment of the outermost element in XML content off it's value.

== Notes ==

  * "wrapper" could be "container" or some such thing.
  * The attribute could be allowed regardless of the value of @type, but 
only be meaninful if @type indicates an XML type.

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 19 Apr 2005 23:22:46 +0200

> http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper

Definitely better!

+1 for me

-- 
Thomas Broyer

---

From: "Roger B." <[email-masked]>
Date: Tue, 19 Apr 2005 19:08:12 -0500

-1 for me.

--
Roger Benningfield

---

From: Graham <[email-masked]>
Date: Wed, 20 Apr 2005 03:21:31 +0100

I don't see the point of this. The problem Sam discussed can be solved 
without it and without requiring the div. Death to "the div is not part 
of the content".

i) Encourage xhtml users to wrap content in a div
ii) Require that they before adding any wrapper, they check whether 
there already is one, and use that instead. This prevents telescoping 
divs.

I'd also request this:
iii) Require that xhtml and *xml content elements have only a single 
child node. That is, all xml must be wrapped in an enclosing element 
(eg <content>text <b>bold</b> more text</content> would be invalid).

Graham

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 20 Apr 2005 11:29:00 +0300

> (eg <content>text <b>bold</b> more text</content> would be invalid).

-1. The Atom content element is the wrapper.

If your rendering mechanism requires a single root but not 
atom:content, shouldn't it be your responsibility to add it?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 20 Apr 2005 09:53:34 +0100

Henri Sivonen wrote:
> If your rendering mechanism requires a single root but not atom:content, 
> shouldn't it be your responsibility to add it?

Not if the content formats have single roots by design.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Wed, 20 Apr 2005 10:57:21 +0100

> atom:content, shouldn't it be your responsibility to add it?

You misread my intent. Requiring a single root (as the XML spec itself 
does) means there's always a hook available to put the namespace 
declaration, negating the need for ever adding an additional wrapper.

Graham Parks

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 20 Apr 2005 13:24:24 +0300

> Not if the content formats have single roots by design.

Yes, */xml and */*+xml obviously require a single root. However, 
type='xhtml' is a fragment--not a full XHTML doc.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Antone Roundy <[email-masked]>
Date: Wed, 20 Apr 2005 08:15:33 -0600

On Wednesday, April 20, 2005, at 04:24  AM, Henri Sivonen wrote:
>>>> iii) Require that xhtml and *xml content elements have only a 
>>>> single child node. That is, all xml must be wrapped in an enclosing 
>>>> element (eg <content>text <b>bold</b> more text</content> would be 
>>>> invalid).
Here's the relevant spec text for */xml and */*+xml:

        If the value of "type" ends with "+xml" or "/xml"
        (case-insensitive), the content of atom:content MAY include child
        elements, and SHOULD be suitable for handling as the indicated
        media type.  If the "src" attribute is not provided, this would
        normally mean that the "atom:content" element would contain a
        single child element which would serve as the root element of the
        XML document of the indicated type.

* MAY include child elements, not MUST or even SHOULD
* "this would normally mean ... a single child element which would 
serve as the root element of the XML document of the indicated type" -- 
not " MUST/SHOULD ... a single child element ..."

It looks to me like fragments of other types could easily end up in 
there too.

> declaration, negating the need for ever adding an additional wrapper.

So requiring a wrapper to be added to the content when the author 
didn't put one there, and not providing a way to signal the author's 
intent is better than giving the publishing software a way to add and 
signal the presence of a software-generated wrapper or publish without 
an extra wrapper?  If the only issue were the possibility of cascading 
wrappers, that might be so, but I for one don't agree that adding even 
a single wrapper is always a benign process.  We certainly can't be 
sure of this for all future XML fragment types that might get embedded 
in Atom documents.

---

From: Graham <[email-masked]>
Date: Wed, 20 Apr 2005 18:39:13 +0100

On 20 Apr 2005, at 3:15 pm, Antone Roundy wrote:

> an extra wrapper?

Actually I was thinking about this and you're right, it isn't benign to 
an XHTML fragment into a block (by adding a div) or whatever for no 
reason. That put's me in favor of Sam's spec, but I currently the 
explanation of why and how it should work is insufficient:

    The XHTML div element itself MUST NOT be considered part of the 
content.

Expanding:

    Note the intended content is that inside the XHTML div and so the 
div itself MUST
    be discarded.

I'd like some mention one way or the other of what happens to 
attributes placed on the div. I presume they'd be ignored and shouldn't 
be used.

Graham

---

From: Graham <[email-masked]>
Date: Wed, 20 Apr 2005 18:49:15 +0100

Just to address the Pace. I support it, but I don't think it's 
necessary to add it to XML data types, since "normally [this would] 
mean that the "atom:content" element would contain a single child 
element which would serve as the root element of the XML document of 
the indicated type", which is where you put the namespace, so you'd 
never need a wrapper, so we can drop the attribute and assume its value 
is "none".

For XHTML, there's almost no reason not to add the div, so we might as 
well drop the attribute here and use assume its value is "dispose".

Handily this means your Pace can be implemented with no changes to the 
current draft.

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 20 Apr 2005 20:53:46 +0200

Graham wrote:
> Just to address the Pace. I support it, but I don't think it's necessary 
> to add it to XML data types, since "normally [this would] mean that the 
> "atom:content" element would contain a single child element which would 
> serve as the root element of the XML document of the indicated type", 
> which is where you put the namespace, so you'd never need a wrapper, so 
> we can drop the attribute and assume its value is "none".

I quite agree.

> well drop the attribute here and use assume its value is "dispose".

For XHTML, there's almost no reason to add a div if it's not needed or 
wanted by the author.

I'd expect my feed and entry titles not to be block-content but rather 
inline content, so a div wouldn't be an appropriate container regarding 
its structural meaning.

People wanting containers to carry their XHTML namespace declarations 
(in order to produce prefix-free documents) can choose among the 
inline-level span or the block-level div elements. If their content is 
already in a container (e.g. a single paragraph summary), they can use 
it as the xmlns holder.

Moreover, not requiring a div container discards at the same time the 
questions such as what to do with its attributes? should we state that 
the div container MUST NOT have any attribute other than the XHTML 
namespace binding? etc.
The spec could still provide examples and suggest such a use of an 
almost-meaningless container, without mandating it.
This does not mean either that the "could validly appear within a XHTML 
div element" wording is to be removed! but it should apply to the Text 
Construct element. It could as well be more precise (using a SHOULD) 
depending on the text construct element, saying the atom:title element 
SHOULD contain XHTML text and markup that could validly appear within an 
XHTML span element: the span content model is a subset of the div one so 
this doesn't interfere with the preceding MUST. It would only be an 
indication of which kind of content (inline or block) is expected.

I must admit I still can't understand why the div container was 
introduced an how it has survived 'til now... (this is NOT a criticism, 
just a remark; I'd be glad if someone could point me to the thread(s) 
where it has been discussed and adopted)

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Wed, 20 Apr 2005 15:07:07 -0400

> where it has been discussed and adopted)

Take a look at the documents here:

<http://groups-beta.google.com/group/bloggerDev/browse_thread/thread/af9033f3a3f4c7fe/c8e1f7e045d346c9#c8e1f7e045d346c9>

-1 to the Pace, BTW. Graham's covered the reasons.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 20 Apr 2005 20:13:37 +0100

On 20 Apr 2005, at 7:53 pm, Thomas Broyer wrote:

> inline content, so a div wouldn't be an appropriate container 
> regarding its structural meaning.

Let me stop you right there. The first thing to note is that the div is 
trivial to add and will be discarded straight away by the consumer. 
Therefore:
- It does not change the meaning of the fragment
- It is not hard to do

Therefore we can conclude the cost, even to people that don't need it, 
is essentially zero.

> already in a container (e.g. a single paragraph summary), they can use 

This is exactly the benefit of the required and then discarded div. 
Without it, a significant proportion of users has to add chuff within 
their content that may change its meaning.

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 20 Apr 2005 22:39:15 +0200

> their content that may change its meaning.

Not if:
  - they're suggested to use span for the title and div elsewhere, or
  - become aware they don't need such a container (whether it's part of 
the content or not) if they use prefixes (to the atom elements -even a 
simple "a:"-, so they don't have to modify their XHTML which is almost 
always served without prefix, as per the XHTML DTD and per HTML 
compatibility for non-supporting browsers)

And since the Atom spec uses the "atom:" convention to name the 
elements, I think a significant proportion of users will use the same 
convention will find the forced div container quite "bizarre" and 
*really* meaningless: "what the hell have I to add a div element? 
moreover in my titles which I expect to inline content? well, OK, this 
is just a discarded container, but, well, it's not really clean to 
transform inline content into block content and still have it behave as 
inline content, isn't it?"

I'm sincerely convinced people should *choose* to use a meaningless 
container to carry their namespace decl when they don't *want* to use 
prefixes and/or don't *want* to declare it elsewhere (e.g. on the 
atom:feed, atom:entry or atom:content). If they just imitate someone 
else's feed without knowing what is a div (block content) and use it for 
their XHTML title, they'll quickly learn that div is a block-level 
container that does not suit the title needs. They'll ask (themselves, 
Google or someone else), they'll find (use span or use prefixes) and 
they'll *choose*.

Note to Robert: I can't find anything meaningful on the bloggerDev group 
about "XHTML div" or "div container"... The link you gave me points to a 
one-message thread where someone uses 3 embedded divs for testing, but I 
can't find out how it's related to this discussion...

-- 
Thomas Broyer

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 21 Apr 2005 03:07:31 +0200

On Tue, 19 Apr 2005 22:18:23 +0200, Antone Roundy <[email-masked]>  
wrote:

> content[type="xhmtl"] with an optional attribute to indicate whether the  
> top level element of XML content is a disposable wrapper or part of the  
> content.

I really see no point in this. Well, I do, but it's not worth the hazzle  
of yet another attribute. Thus: -1.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»