Subject: PaceXhtmlNamespaceDiv

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 12:52:43 -0700

+1, but I wouldn't object to a variant that required either the DIV 
with a namespace declaration OR for the namespace to be declared in 
<content> or before <content>.  Examples of what I'd think was 
acceptable:

<feed ... xmlns:xhtml="..." />
	...
	<content>This is <xhtml:b>bold</xhtml:b></content>

OR

<content xmlns:xhtml="..." />This is <xhtml:b>bold</xhtml:b></content>

OR

<content><div xmlns="..." />This is <b>bold</b></content>

Here's what I think is just plain ugly and shouldn't be allowed:

<content>This is <b xmlns="..." >bold</b></content>

OR

<content>This is <xhtml:b xmlns:xhtml="..." >bold</xhtml:b></content>

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 7 Feb 2005 22:09:28 +0200

> 	<content>This is <xhtml:b>bold</xhtml:b></content>

This is against the Pace. Are you really supporting the pace?

> <content xmlns:xhtml="..." />This is <xhtml:b>bold</xhtml:b></content>

This is against the Pace, too.

> <content><div xmlns="..." />This is <b>bold</b></content>

This one is against the pace as well. Also, the 'b' element would be in 
the same namespace as 'content', which seems wrong.

> <content>This is <b xmlns="..." >bold</b></content>

IMO, that should be allowed. Atom has no business in restricting the 
syntactic sugar provided by Namespaces in XML.

> <content>This is <xhtml:b xmlns:xhtml="..." >bold</xhtml:b></content>

IMO, this on should be allowed on the same grounds.

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

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 12:18:52 -0800

Ok, now that I'm thinking about this more, I'm changing my initial +0 to 
+1.  This just makes sense.  There does need to be a container for the 
XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.

- James M Snell

Antone Roundy wrote:
> 
> +1, but I wouldn't object to a variant that required either the DIV with 
> a namespace declaration OR for the namespace to be declared in <content> 
> or before <content>.  Examples of what I'd think was acceptable:
>

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 07 Feb 2005 21:25:35 +0100

> matter where the xmlns is declared... any ancestor element will do.

I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for "string based generators" be to apply it on 
the DIV element?

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

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 7 Feb 2005 22:28:08 +0200

On Feb 7, 2005, at 22:18, James M Snell wrote:

> There does need to be a container for the XHTML and div is a solid, 
> logical choice.

The container is the Atom Text construct itself!

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

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 12:35:49 -0800

Yes, sorry I wasn't clear.  Not *only* on ancestor elements. any of the 
following cases should be allowed.

<feed>
   <entry>
     <content>
       <xhtml:div xmlns:xhtml="..." />
     </content>
   </entry>
</feed>

<feed>
   <entry>
     <content xmlns:xhtml="...">
       <xhtml:div />
     </content>
   </entry>
</feed>

<feed>
   <entry xmlns:xhtml="...">
     <content>
       <xhtml:div />
     </content>
   </entry>
</feed>

<feed xmlns:xhtml="...">
   <entry>
     <content>
       <xhtml:div />
     </content>
   </entry>
</feed>

- James M Snell

Anne van Kesteren wrote:
> James M Snell wrote:
> 
>>
>> Ok, now that I'm thinking about this more, I'm changing my initial +0 
>> to +1.  This just makes sense.  There does need to be a container for 
>> the XHTML and div is a solid, logical choice.  I don't think it should

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 07 Feb 2005 21:39:14 +0100

James M Snell wrote:
> [snip]

And surely |<div xmlns="...">| so people who append strings together can 
  do so easily.

I still wonder what the advantage of this conainer is. Especially since, 
as pointed out, the CONTENT element already is the container.

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 12:44:47 -0800

Nah, I don't buy it.  XHTML is just a special case of an XML content and 
if we were embedding some XML data (say an atom:feed) it wouldn't make 
any sense (under the assumption that the <content /> element is top 
level container) for us to do:

<content type="application/atom+xml">
   <head>
     ...
   </head>
   <entry>
     ...
   </entry>
</content>

In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.

- James M Snell

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 13:45:41 -0700

> This is against the Pace. Are you really supporting the pace?

Yes, while saying that I would be satisfied with this too--as long as 
the namespace declaration doesn't occur inside <content> unless in a 
DIV that contains everything else that's in <content>.

> This is against the Pace, too.
Yep.  Same answer.

> This one is against the pace as well. Also, the 'b' element would be 
> in the same namespace as 'content', which seems wrong.

Gaah!  I left off the </div> and accidentally put a "/" in the end of 
the <div> tag.  I meant <content><div xmlns="...">This is 
<b>bold</b></div></content>.  One of those mistakes I could understand, 
but how did I manage to do both at once?

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 7 Feb 2005 22:50:40 +0200

For the record, the additional loop that the div would save in a 
DOM-based client is not that hard:

copyLangAndBase(atomTextCostruct, targetDivInTemplate);
for (Node n = atomTextCostruct.getFirstChild(); n != null; n = 
n.getNextSibling()) {
	targetDivInTemplate.appendChild(templateXhtmlDocument.importNode(n, 
true));
}

Is that too much to ask from clients?

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

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 07 Feb 2005 21:51:22 +0100

> <content type="application/atom+xml">

I do not follow this example.

> well-formed document and XHTML is just a special case of XML content.

So you want a DIV as wrapper element for TITLE and similar elements as well?

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 15:58:01 -0500

> the most logical thing for "string based generators" be to apply it on 

I'm confused.  If you are opposed to this pace, then what div element?

It may also be helpful to look at a specific feed, for example this one:

http://www.imc.org/atom-syntax/mail-archive/msg12902.html

Experiment with alternate serializations if you like.

The important question is whether the <div> element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?

- Sam Ruby

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 07 Feb 2005 22:01:41 +0100

Sam Ruby wrote:
>>> the XHTML and div is a solid, logical choice.  I don't think it 
>>> should matter where the xmlns is declared... any ancestor element 
>>> will do.
>>
>> I'm still -1. But I was wondering, why only ancestor elements? 
>> Wouldn't the most logical thing for "string based generators" be to 
>> apply it on the DIV element?
>

That was a question in reply to what James wrote. It appeared to be an 
error.

> Atom entry is POSTed to a blog, is the div part of the content?

If the page is adopted, which I hope not, it MUST NOT be part of the 
content. If the page is not adopted it MUST be part of the content.

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 12:59:31 -0800

Anne van Kesteren wrote:
> James M Snell wrote:
> 
>> Nah, I don't buy it.  XHTML is just a special case of an XML content 
>> and if we were embedding some XML data (say an atom:feed) it wouldn't 
>> make any sense (under the assumption that the <content /> element is 
>> top level container) for us to do:
>>

The point is that <content /> should not be viewed as the root element 
for contained XML.  The XML content should be able to stand on it's own, 
indepedently of the content or text construct element as well-formed XML.

> So you want a DIV as wrapper element for TITLE and similar elements as 

For Text construct and Content, if XHTML is used, there should be a DIV. 
  If someone wants to use XHTML for title, then yes, they should use a 
DIV. Otherwise, they can use plain text.

- James M Snell

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 7 Feb 2005 23:07:53 +0200

> Nah, I don't buy it.  XHTML is just a special case of an XML content

Atom has chosen to treat type='XHTML' (as opposed to 
type='application/xtml+xml') as a special case.

> wouldn't make any sense (under the assumption that the <content /> 
> element is top level container) for us to do:
>

By that logic, you'd have to include the 'html', 'head', 'title' and 
'body' XHTML elements as well. See http://macsanomat.com/atom for an 
example of that. (0.3 was silent on subsetting the XHTML document, so 
logically I had to assume it was not allowed, although the 
ViewSourceClan thought it was.)

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

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 16:21:52 -0500

Anne van Kesteren wrote:

> Sam Ruby wrote:
> 
>>>> Ok, now that I'm thinking about this more, I'm changing my initial 
>>>> +0 to +1.  This just makes sense.  There does need to be a container 
>>>> for the XHTML and div is a solid, logical choice.  I don't think it 

I can easily sit back and adopt a "wait and see" and "I told you so" 
attitude, but by now it should be obvious that I care too much about the 
success of this format and protocol to do that.

If this Pace is not adopted, the following predictions can be made:

   1) Graham (who uses proper XML tools) will have to do more work.
   2) Tim (who uses string concatenation) will have to do more work.
   3) More feeds will be harder to read (that's why I asked you to
      experiment with alternate serializations.
   3) More feeds will be invalid (content in atom namespace)
   4) More feeds will be incorrect (in the sense that Tim's feed does
      accurately reflect the content of his entries).
   5) For some combinations of clients and servers, entries produced
      via an HTTP POST will end up with multiple <div>s.

Meanwhile, now that the location where the namespace can be declared 
details have been removed from this pace, Henri can continue to do a 
DOM-to-DOM copy.

I stand by my original statements:

   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: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 16:54:21 -0500

> success of this format and protocol to do that.

After watching this WG fail to communicate clearly on this matter, and 
make a variety of arcane XML serialization mistakes in the course of 
discussion, it's clear to me that Sam is right.

+1 to PaceXhtmlNamespaceDiv

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 07 Feb 2005 23:55:38 +0000

>   3) More feeds will be invalid (content in atom namespace)

Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.

I'm +1 on this pace, sometimes a judicious hack is the right thing to 
do. I suspect it could result in <div> nesting - call it gut feeling 
(it's an escaping mechanism after all).

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 19:05:07 -0500

> Guide - I'm somewhat unsympathetic now if we find ourselves bitten.

Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.

atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 00:16:37 +0000

> not expect to find in xhtml.

Agreed (but we have already decided to allow that possibility at the 
container level). Still +1.

cheers
Bill

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 14:29:40 +0200

>   1) Graham (who uses proper XML tools) will have to do more work.

Which tools? How much more? One loop more?

(FWIW, I do not consider Apple's Core Foundation "XML parser" a proper 
XML tool.)

>   2) Tim (who uses string concatenation) will have to do more work.

When I did a string concatenation implementation, using colonified 
names was not a big deal.

>      via an HTTP POST will end up with multiple <div>s.

I can anticipate that happening either way.

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

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 14:35:58 +0200

On Feb 7, 2005, at 22:58, Sam Ruby wrote:

> If you are opposed to this pace, then what div element?

If the pace does not get through, it is still permissible to put a div 
in there as part of the content. In fact, either way it is permissible 
to add meaningless extra divs, since a div can nest in a div.

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 13:56:30 +0100

>>>   1) Graham (who uses proper XML tools) will have to do more work.

I'd like to see a concrete example where this is a problem. As far as I 
can tell, the content construct itself can be considered the container, 
so whether or not a mandatory DIV element is present, there will always 
be a useable container element.

>>>   2) Tim (who uses string concatenation) will have to do more work.

Nothing changes for Tim, he can continue to produce the output he's 
producing currently.

>>>      experiment with alternate serializations.

Whether something is easier to read seems to be a matter of taste: I 
certainly prefer a globally scoped XHTML namespace declaration, and no 
additional DIV elements.

> not expect to find in xhtml.

Yes, but there are many other things people may get wrong when producing 
Atom. In particular, I would tend to trust those who do generate XHTML 
instead of HTML to get namespace declarations right as well.

Below are some comments that I just added to the Pace:

"- Requiring the namespace declaration on a particular element means (a) 
profiling XMLNS, (b) defeating potential space optimizations by having 
the namespace declaration only once, and (c) breaks XML toolkits that do 
not provide full control over where namespace declarations appear.

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."

Best regards, Julian

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

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 13:14:47 +0000

Julian Reschke wrote:
  Below are some comments that I just added to the Pace:
> profiling XMLNS, 

I don't have a problem with this. Taking XMLNS warts and all cause more 
problems that it solves.

> (b) defeating potential space optimizations by having 
> the namespace declaration only once, and 

Do you have a sense of how serious not allowing these potential 
optimizations is?

> (c) breaks XML toolkits that do 

They sound like dysfunctional toolkits. Can you name some (ie it might 
be persuasive if it came to light that a scad of PHP users were left 
high and dry).

> element for HTML content for reasons of symmetry."

+1 to that symmetry.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Tue, 08 Feb 2005 08:44:08 -0500

> Nothing changes for Tim, he can continue to produce the output he's 

What Tim is syndicating does not match the content on his site.  Without 
this Pace, the div element would need to be considered part of the content.

> certainly prefer a globally scoped XHTML namespace declaration, and no 

Fair.  However, a globally scoped XHTML namespace declaration will 
require every xhtml tag to be explicitly namespaced.

>>> content is lifted out using namespace aware tools. In other words, 
>>> the container markup format is just dandy, but the content they carry 
>>> is potentially trashed. If we condone default namespaces this is what 
>>> we can expect to happen. We discussed warning people about this 
>>> broken piece of XML technology last year and it was punted to an 
>>> Implementors Guide - I'm somewhat unsympathetic now if we find 
>>> ourselves bitten.

Content type="XML" should be able to hold any type.  type="XHTML" should 
be a valid XHTML fragment.

> instead of HTML to get namespace declarations right as well.

I have personally seen such invalid feeds.  In large quanties.  I've 
worked with the individuals that have produced such feeds, but 
ultimately such an approach doesn't scale.

> not provide full control over where namespace declarations appear.

Nothing in this pace requires such a declaration.

> element for HTML content for reasons of symmetry."

Are you suggesting that the following would need to be required for 
symmetry?

   &lt;div&gt; ... &lt;/div&gt;

Suggesting this seems petty.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Wed, 09 Feb 2005 00:54:01 +1100

> element for HTML content for reasons of symmetry."

I thought with @type="HTML" the content gets escaped and thus there is
nothing to put into a namespace.

e.

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 15:55:34 +0200

On Feb 8, 2005, at 15:14, Bill de hÓra wrote:

>> "- Requiring the namespace declaration on a particular element means 
>> (a) profiling XMLNS,
>
> I don't have a problem with this. Taking XMLNS warts and all cause 
> more problems that it solves.

Restricting XMLNS is no longer on the table.

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 14:59:48 +0100

> this Pace, the div element would need to be considered part of the content.

What difference does this make in practice? HTML defines DIV as...

"These elements define content to be inline (SPAN) or block-level (DIV) 
but impose no other presentational idioms on the content."

(<http://www.w3.org/TR/html401/struct/global.html#edef-DIV>)

> require every xhtml tag to be explicitly namespaced.

(unless we make it the default namespace, which usually won't make sense).

>> (a) profiling XMLNS, (b) defeating potential space optimizations by 
>> having the namespace declaration only once, and (c) breaks XML 
>> toolkits that do not provide full control over where namespace 
>> declarations appear.
> 
> 

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

Am I looking at the wrong pace? 
(<http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv>)

>   &lt;div&gt; ... &lt;/div&gt;

Yes.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 15:04:44 +0100

> I don't have a problem with this. Taking XMLNS warts and all cause more 

Well, it also enables us to relatively painlessly combine Atom and XHTML 
in the same document.

>> (b) defeating potential space optimizations by having the namespace 
>> declaration only once, and 
> 
> 

I just tried with Tim's feed, and I am getting a reduction of around 4%. 
Your mileage may vary a log depending on typical length and structure of 
content.

>> (c) breaks XML toolkits that do not provide full control over where 
>> namespace declarations appear.
> 

I wrote one myself back when Xerces' serializer was broken in regards of 
namespace handling. For the same reasons, similar serializers may exist 
elsewhere.

Best regards, Julian

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 16:02:48 +0200

On Feb 8, 2005, at 15:44, Sam Ruby wrote:

> What Tim is syndicating does not match the content on his site.  
> Without this Pace, the div element would need to be considered part of 
> the content.

What's the harm?

>  However, a globally scoped XHTML namespace declaration will require 
> every xhtml tag to be explicitly namespaced.

Or the Atom tags to be colonified.

> Suggesting this seems petty.

I agree. However, I have similar sentiments towards requiring the div 
with XHTML.

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 15:07:14 +0100

Yes.

I think the issue here is that the Pace combines different requirements 
(a: let's have a single container element, and b: let's force people to 
explicitly declare their XHTML ns in a single place). It would be good 
for the discussion if we could agree about what is still in scope, and 
what in particular we want to achieve.

Best regards, Julian

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 16:22:12 +0200

On Feb 8, 2005, at 15:59, Julian Reschke wrote:

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

The abstract no longer matches the proposal. This seems to cause 
confusion.

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

---

From: Sam Ruby <[email-masked]>
Date: Tue, 08 Feb 2005 09:30:50 -0500

> (<http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv>)

I have just updated the Pace to remove from the abstract text which is 
no longer reflected in the proposal.

- Sam Ruby

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 08 Feb 2005 16:34:29 +0100

> be a valid XHTML fragment.

I hope type="XML" is just an example?

(I still think we should revert it back to TYPE and MODE where MODE is 
optional and TYPE has a fixed value of "text/plain".)

---

From: Robert Sayre <[email-masked]>
Date: Tue, 08 Feb 2005 13:28:40 -0500

> element for HTML content for reasons of symmetry."

I'm sorry, that is ridiculous.

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Wed, 09 Feb 2005 13:39:29 +0900

At 22:59 05/02/08, Julian Reschke wrote:
 >http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv

I have looked at this pace only just very recently, after
following the discussion. So I first want to make sure I
get the current status of this proposal right.

As I currently read it, it does:

1) Require an <xhtml:div> as the only direct child of content of type XHTML
2) Not limit the placement of namespace declarations in any way above
    and beyond those given in the Namespace spec.
3) Not require any specific namespace prefixes.

If 2) and 3) are correct, I can live with this proposal. Anything
changing 2) or 3), as may have been previously in this Pace, would
get something like a -2 from me. Specs, in particular such fundamental
ones as XML Namespaces, are there to be used as is, not to be tweaked.

As for 1), I could live with it, but the rationale given for it in the
current version says:
"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."

This doesn't seem to match the proposal, where Namespace declarations
are only used in the examples, but not mentioned in the text.
So while (as said above) I can live with 1), insisting on 1) without
a better rationale doesn't seem to make sense to me.

If the concern expressed in the rationale is important (and I can
agree it is), then addressing this concern can be done in less
constricting ways, i.e. by replacing the requirement for a <div>
with something like:

Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an <xhtml:div>
element as the content of the <atom:content> element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way.

Regards,     Martin.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 09 Feb 2005 17:41:53 +1100

> this specification does not limit the placement of such declarations

+1

---

From: Sam Ruby <[email-masked]>
Date: Wed, 09 Feb 2005 08:28:16 -0500

> ones as XML Namespaces, are there to be used as is, not to be tweaked.

Agreed.

> this specification does not limit the placement of such declarations

Here's the key question.  Consider the following XML fragment:

   <summary type='XHTML'><div xmlns='http://www.w3.org/1999/xhtml'>Hey, 
this is my space, if I want to run a picture of a chair I can. And it’s 
a <em>nice</em> chair.</div></summary>

Given this fragment, what is the value of the summary?  Is the div 
element to be considered part of the format (and therefore not part of 
the summary).  Or is the div element to be considered part of the 
summary itself.

Assume for the moment that it is part of the summary.  You can give the 
author a bit of poetic license and say that this is valid.  If you look 
at Tim's feed, you will see that a similar approach is used for 
syndicating content.  The validity of that is not quite so clear.

Now consider what happens when data is resyndicated (Planet XML, for 
example).  If such tools add a div element, and the div element is 
considered part of the summary/content, then they are technically wrong. 
  But this will likely go unnoticed for a while as visually the results 
appear correct.

Now consider what happens if tools that implement the protocol do 
likewise.  Get a feed, modify an entry, and POST it.  Over time, you 
will end up with telescoping divs.

The solution that some will likely come up with will be to ignore 
enclosing divs.

Some may do this.  Some may not.

Now assume for the moment that the div is not part of the summary.

- Sam Ruby

---

From: James M Snell <[email-masked]>
Date: Wed, 09 Feb 2005 08:26:36 -0800

> The solution that some will likely come up with will be to ignore

Hmm.. considering DIV as being part of the summary is a bit like saying 
the <feed /> element in the content following example is part of the 
enclosing content... it just doesn't make sense.

<feed>
   <entry>
     <content ...>
       <feed>
         <entry/>
       </feed>
     </content>
   </entry>
</feed>

If a DIV is required for XHTML content, tools working with Atom should 
deal with it accordingly and properly without us having to specify a 
special handling case for XHTML content that does not apply to any other 
type of XML content.

If tools want to add additional div's in addition to the one in the 
content/summary, so be it, it is entirely up to that up to that 
particular tool to do implement its own brand of silliness.

- James M Snell

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 10 Feb 2005 00:25:11 +0200

On Feb 9, 2005, at 15:28, Sam Ruby wrote:

> this is my space, if I want to run a picture of a chair I can. And 
> it’s a <em>nice</em> chair.</div></summary>
>

The div is part of the summary according to current spec text.

> Assume for the moment that it is part of the summary.  You can give 
> the author a bit of poetic license and say that this is valid.

It is correct, because a div can correctly be a child of div and the 
content model of Text constructs is defined to be the content model of 
div.

> If you look at Tim's feed, you will see that a similar approach is 
> used for syndicating content.  The validity of that is not quite so 
> clear.

It is correct from the syntactic point of view, although I understand 
your point that it may not be part of what the ongoing CMS treats as 
content internally.

> example).  If such tools add a div element,

Your argument is based on the assumption that resyndicators need or 
want such a div. But why would such an aggregator add the div? While a 
CMS may successfully engage in string concatenation, because it 
internally restricts the string serialization of the content, 
resyndicators cannot rely on a particular serialization and, therefore, 
must not attempt grab a substring of unparsed XML source and try to 
concatenate it into an unparsed string template. Since resyndicators 
need to deal with all of XMLNS, why would they include extra divs that 
are convenient for string concatenators? The serialization code of 
resyndicators has to deal with synthesizing namespace declarations 
and/or namespace prefixes anyway, so I don't see how  resyndicators 
would benefit from adding an extra wrapper.

> will end up with telescoping divs.

Again, you are assuming XHTML-capable clients want to behave like tag 
soup concatenators. Why not use type='HTML' for that?

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

---

From: Sam Ruby <[email-masked]>
Date: Thu, 10 Feb 2005 10:35:35 -0500

> The div is part of the summary according to current spec text.

That's what I want to change.  I've updated the Pace to make this 
clearer.  I replaced the abstract completely, and added one sentence to 
the proposal.

New abstract:

New spec text:

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

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 16:48:28 +0100

>   The xhtml:div element itself MUST NOT be considered part of the

I find it a bit problematic to use "common practice" in Atom feeds as 
justification for spec changes. Let's make the spec as clear and simple 
as possible. If this is in conflict with common usage in experimental 
Atom feeds, so be it.

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Thu, 10 Feb 2005 11:02:20 -0500

Julian Reschke wrote:

>> clearer.  I replaced the abstract completely, and added one sentence 
>> to the proposal.
>>
>> New abstract:
>>

That is consistent with your prior statement that you don't believe that 
implementation issues should affect the format:

http://www.imc.org/atom-syntax/mail-archive/msg12699.html

Yes, I want a spec that is simple.  I also want a spec that average 
people can implement simply and correctly.

We have seen on this very mailing list people who have an above average 
understanding of XML trip over this particular area numerous times.

I am not content to create a format for which the answers to such common 
user errors is "so be it".

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 17:18:30 +0100

> http://www.imc.org/atom-syntax/mail-archive/msg12699.html

What I said is that very *specific* implementation issue shouldn't 
affect the format. Please cite correctly. I also posted the following 
clarification in 
<http://www.imc.org/atom-syntax/mail-archive/msg12697.html>:

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

> user errors is "so be it".

Nor am I. The question is what's the best way to enhance the spec. One 
alternative suggestion was made by Martin Dürst in 
<http://www.imc.org/atom-syntax/mail-archive/msg13531.html>:

"Note: It is important to make sure that correct namespace declarations
in any way."

Best regards, Julian

---

From: Brett Lindsley <[email-masked]>
Date: Thu, 10 Feb 2005 10:17:48 -0600

I was working with some compatibility issues with RSS 1.0/2.0 vs.
Atom and noticed that both RSS 1.0 and RSS 2.0 have a <description>
but there is no equivalent in Atom for the head. A description or
<summary> in the head would be useful for listing services to
provide a human readable description of what the feed is about
(besides just the title). It would also be useful for searching for
a particular feed of interest.

Brett Lindsley, Motorola Labs

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 10 Feb 2005 17:15:09 +0100

Sam Ruby wrote:
>> justification for spec changes. Let's make the spec as clear and 
>> simple as possible. If this is in conflict with common usage in 
>> experimental Atom feeds, so be it.
> 

However, what is the problem with people using a DIV element inside 
SUMMARY and the CONTENT element if they wish to do so?

By the way, I have read the thing you wrote about things like planet 
copy the contents and put it in their own DIV element but if that is how 
they are going to treat Atom, Atom will not be solving anything and will 
just be another RSS I guess.

Authors who do copy and paste and others should always validate their 
feed. I guess the feed validator could flag elements that are in the 
Atom namespace and should not be there according to the latest updates 
of the Atom namespace.

Eventually, I guess it is about getting the major weblog systems and 
companies to get their implementation right. The Atom WG and other 
people should also provide tutorials on how to create Atom feeds and how 
to make sure everything works as it should.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 10 Feb 2005 18:22:45 +0200

On Feb 10, 2005, at 18:02, Sam Ruby wrote:

> We have seen on this very mailing list people who have an above 
> average understanding of XML trip over this particular area numerous 
> times.

Those trip-ups have not been as much about div vs. no div but about 
XMLNS which we can't and should not attempt to change. I should also 
note that typed examples on the list and output from debugged 
serializers are different things.*

* Aka. the "tools will save us" argument. Despite the "tools will save 
us" argument being unpopular, I think it is unwise for an average 
developer to approach XMLNS without proper tools.

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

---

From: Sam Ruby <[email-masked]>
Date: Thu, 10 Feb 2005 11:35:16 -0500

Julian Reschke wrote:

> Sam Ruby wrote:
> 
>> That is consistent with your prior statement that you don't believe 
>> that implementation issues should affect the format:
>>
>> I am not content to create a format for which the answers to such 
>> common user errors is "so be it".
> 

My issue with that wording is that it doesn't make it clear whether the 
xhtml:div that is added is to be considered a part of the content or not.

Put another way, how does the consumer know that if a given xhtml:div 
element is part of the content, or was added per the above?

Julian, you previously said "Let's make the spec as clear and simple as 
possible."  How about this:

   xhtml:div is required.  xhtml:div is not part of the content.

Clear.  Simple.  And difficult to get wrong.

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 17:55:02 +0100

Sam Ruby wrote:
>> ....

I'd assume it's part of the content because that's what the spec 
currently says.

> element is part of the content, or was added per the above?

It is, unless the spec says otherwise.

> Clear.  Simple.  And difficult to get wrong.

Well, but not sufficient as spec text right?

To summarize my p.o.v.:

- the spec shouldn't require any specific container element for XHTML 
content,

- the spec should warn people about that the child elements MUST be in 
the XHTML namespace if the recipient is supposed to interpret them as as 
XHTML markup,

- whether or not a feed producer puts in a <div> container doesn't seem 
to be relevant to me as it doesn't affect the semantics of what the text 
construct carries.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Thu, 10 Feb 2005 08:56:18 -0800

> Clear.  Simple.  And difficult to get wrong.

I'd much prefer:

   xhtml:div is required. xhtml:div is part of the content.

But I can live with it either way

- James M Snell

---

From: Graham <[email-masked]>
Date: Thu, 10 Feb 2005 16:59:04 +0000

>   The xhtml:div element itself MUST NOT be considered part of the

What does this mean? Define "content" and "considered" please.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 10 Feb 2005 12:30:47 -0500

Henri Sivonen wrote:

> 
> Despite the "tools will save 

Doesn't really matter what your preference is. People *will* generate 
Atom content without "proper tools". They will not learn their lesson 
from a bunch of strict clients. Rather, there will be "street Atom", 
where Atom's namespace will have a bunch of elements with same local 
name as XHTML elements.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 18:46:45 +0100

Robert Sayre wrote:
> 
> Henri Sivonen wrote:
> 
>>
>> Despite the "tools will save us" argument being unpopular, I think it 
>> is unwise for an average developer to approach XMLNS without proper 
>> tools.
>>
> 

So do you think we'll have to live with that, or should the spec be 
clarified/changed to reduce the chance of people getting it wrong?

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Thu, 10 Feb 2005 13:05:28 -0500

> clarified/changed to reduce the chance of people getting it wrong?

I think Sam's approach is best. The objections are all impractical pedantry.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 19:18:35 +0100

> I think Sam's approach is best. The objections are all impractical 

I think the proposal won't really help for cases where people don't know 
what they do and/or use the wrong tools, but adds completely unnecessary 
complexity for everybody else.

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Thu, 10 Feb 2005 13:20:55 -0500

> - the spec shouldn't require any specific container element for XHTML 

We continue to talk past one another.  The above line is key.

Some examples might help.  Perhaps once we are actually understanding 
each other's points, then we can work backward from there to spec text.

So, suppose my XHTML content is:

   <p>What a nice day!</p>

My XHTML container element is <p>.  That is completely my choice.  It is 
not required by the spec.

Now if I place that inside an atom feed, I'm going to get something like 
this (heavily elided, all namespace details omitted):

   <feed>
     <entry>
       <summary>
          <p>What a nice day!</p>
       </summary>
     </entry>
   </feed>

Depending on the how the question is phrased, one could take the 
position that <feed>, <entry>, and <summary> are container elements.  Or 
not.  Again, depending on how the question is phrased.

I don't believe that these elements are the ones that you have an issue 
with.  Correct?

Now, consider a different document, again heavily elided, etc:

   <feed>
     <entry>
       <summary>
          <div>
            <p>What a nice day!</p>
          </div>
       </summary>
     </entry>
   </feed>

The key difference between these two documents is that instead of three 
elements around which there should be no issue, there now are four.  But 
for some reason, this causes a big controversy.

My theory is that the controversy is that people initially assumed that 
this div element was to be considered part of the content and not part 
of the format.  And thereby was mandating that all content have a given 
container element.  An entirely unreasonable mandate.

I agree that this would be an unreasonable mandate.  But I don't want to 
force a top level container element for the xhtml, I want to define a 
bottom level container element in the format for the xhtml.  There is a 
big difference.

The difference between four feed container elements and mandating that 
all xhtml content have a uniform top level container element.  Which 
again, I will agree is an entirely unreasonable assumption.

  - - -

On the optimistic presumption that you are with me so far, I'll press 
on.  What desirable characteristics are there for feed container 
elements in this circumstance?

To answer that question, it is important to understand how CMS software 
tends to be implemented.  In particular, how they are layered.  This is 
difficult as there isn't any one reference implementation that we can 
consult.  We also need to consider software which isn't written yet.  As 
I said, this is diffuclt.

But we can observe common problems that people have had, and try to 
engineer a solution that avoids them.  I hold the belief that if 
somebody writes a simple and clear spec that a significant number of 
people get wrong, that we are looking at a spec bug.

Enough hand waving, onto the problem at hand.  What we are looking at 
here is an xhtml fragment.  Not a complete xhtml document, but some 
fragment of a web page.

Now, fragments tend not to exist independent of a context.  And in 
virtually all xhtml documents I have seen (including the ones I 
produce), any fragment presumes that the xhtml namespace was defined as 
the default namespace earlier in the document (in particular, on the 
document element).

So, a desirable characteristic for a container element would be one in 
which the default namespace can be set.

At this point, the discussion can fragment into any number of different 
directions.

   - - -

One is for those who view XML as merely one potential serialization 
format, and something that their tool takes care of for them.  For them, 
double escaping the content is the right answer, the simplest thing that 
can possibly work, end of discussion.  While neither you nor I are in 
that camp (nor is Norm, and others), I am quite willing to leave that as 
a valid option, as long as it is explicitly declared.

Another is to declare the use of default namespaces as evil, and rewrite 
  both the document and the content to use explicit namespaces on every 
element.  This may very well be where you and I part ways.  If so, 
peace.  Just please give the people who want to use default namespaces 
the same consideration that I am willing to give those who wish to 
double escape.

And finally, there is a desire to create a format that can be done 
entirely with default namespaces, and without the need to rewrite or 
modify the content.

The simple fact is that well formed xhtml does not always exist in the 
form of DOM nodes.  Sometimes it is serialized as a string and stored in 
a file or a MySQL database.  That does not make it any less well formed. 
  It doesn't mean that it wasn't produced by a proper tool.

Not having seen Tim's implementation, I'm just speculating at this 
point, but it probably falls into this category.  Based on the tools he 
is using, he is confident that his content is well formed, even if it is 
stored as a string.  As such, he can confidently use simple string 
concatenation as long as he can be assured that the default namespace is 
correct.

Whether Tim's implementation meets this description or not, mine 
certainly does.  And by looking at the common errors I have seen in 
feeds, I'm pretty sure that many others do too.

  - - -

So, what would a desirable feed container element be for this scenario? 
  I would suggest that it would be something in the xhtml namespace.  If 
it were in the atom namespace, you would have to do something along the 
lines of:

   <atom:summary xmlns:atom="..." xmlns="...">

One could of course, hoist the declaration of the atom namespace to the 
top of the document, at which point you get two declarations of the atom 
namespace.  You can get to exactly one declaration, *if* you explicitly 
specify the namespace prefix on every element, and as I said above, you 
are welcome do this, I just don't want to mandate it.

An alternative would be to put summary in the xhtml namespace.  That 
doesn't feel quite right to me.

A final alternative would be to adopt an element from the xhtml 
vocabulary as a feed level container.  One that connotes that the 
children are expected to be valid children of the <div> element would be 
nice.

  - - -

If you are still with me, what I am proposing is that the simplest and 
cleanest solution for people who like default namespaces would be to 
define the format so that there is an <xhtml:div> element between the 
<atom:summary> and the xhtml fragment that is being syndicated.

If you believe in double escaping, this does not affect you.

If you don't believe in default namespaces, then the difference amounts 
to whether there is three or four enclosing feed elements for you to 
deal with.

  - - -

So, if we can't work together to find appropriate spec wording to make 
this happen, the following predictions can be safely made:

   3) More feeds will be harder to read (that's why I asked for people to

  - - -

All that being said, I am OK with any spec wording that enables one to 
create a document using only default namespaces that:

   1) does not require well formed, serialized XHTML fragments to be
      modified.
   2) is unabiguous as to which elements in the document are part of the
      feed "structure" and which are to be considered the "content" being
      syndicated.

Fair enough?

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 10 Feb 2005 19:34:51 +0000

Sam Ruby wrote:

 > [..snip excellent rationale..]

That is not a desirable characteristic.

> [...]

> the same consideration that I am willing to give those who wish to 

I believe the easiest, most robust, least error-prone approach to this 
sort of problem is to attempt to eliminate default namespace usage 
whenever possible. Every time a default namespace is elided system 
robustness and comprehension are improved - I've never seen it work the 
other way.

> entirely with default namespaces, and without the need to rewrite or 

That is a questionable desire. It leads us directly to promoting the use 
of a div wrapper to protect XHTML from Atom. Any container format that 
can so easily damage content we have to enforce a shim to protect it, 
arguably has a design flaw. Atom is just the most of recent of string of 
flawed container formats.

>   <atom:summary xmlns:atom="..." xmlns="...">

Sam is 100% right this is problem. I arrive at a very different conclusion.

> <atom:summary> and the xhtml fragment that is being syndicated.

It's interesting you call them out so specifically, but no - default 
namespaces are the problem. Free your mind, and all that.

This can be solved in a general way, not just for XHTML, by banning the 
use of default namespaces for Atom elements. That means the Atom format 
would actively subset XMLNS. I see that as a preferable option to 
anything presented in this thread.

[Although it's time past for paces, I have one on this computer 
somewhere for default namespaces, but after I got shouted down last year 
about xmlns="" I didn't think there was much point. Maybe I'll publish 
it on April 1st]

In the meantime I support Sam's position, but think we're missing an 
opportunity to produce a more robust XML container format.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 22:13:55 +0100

> Julian Reschke wrote:

Sam, thanks for the long reply. I'll try my best to dig it and to offer 
constructive remarks...

> not required by the spec.

Yep.

> this (heavily elided, all namespace details omitted):

Yep.

> not.  Again, depending on how the question is phrased.

Fine with me.

Yes.

> container element.  An entirely unreasonable mandate.

Well, the current spec says it's part of the content. I personally feel 
it really doesn't matter. Adding DIVs around XHTML content doesn't 
change the semantics of the content, in particular if it doesn't carry 
any additional attributes.

So, I wouldn't have any problems with recipients that collapse multiple 
nested xhtml:div elements into one or none (in absence of other 
attributes on it).

> bottom level container element in the format for the xhtml.  There is a 

It's still hard to see the difference, It's certainy not obvious on the 
syntactical level, and at the end of the day, that's what we are 
discussing here, right?

> on.  What desirable characteristics are there for feed container 

Not entirely, but trying :-)

> people get wrong, that we are looking at a spec bug.

Sure. But, are we looking at the whole set of implementors, or only 
those who actually read the spec? We all know that those sets aren't 
identical...

Yes.

> the default namespace earlier in the document (in particular, on the 

Well, that depends how you define "fragment". For instance, I can use 
XSLT to produce that fragment and I certainly don't have to make any 
assumptions about default namespaces. The XSLT processor cares for me. 
The same thing applies when serializing a node set from an 
namespace-aware DOM (at least that's what I'd expect and MSXML has been 
doing for years now).

> which the default namespace can be set.

I disagree that this is important, but the atom text constructs do have 
that characteristic already.

> a valid option, as long as it is explicitly declared.

Yes (although I'd like to see the spec to at least state that using the 
HTML type and double-escaping may reduce the number of recipients that 
actually will see the intended markup; separate discussion).

> the same consideration that I am willing to give those who wish to 

Ah! Yes, there's a camp of people who dislike default namespaces. I'm 
not part of that group. Default namespaces are a useful method to keep 
the XML readable, but as you said, they must be used carefully. I've 
explained XPath1-vs-default-namespaces too many times in my life :-)

> entirely with default namespaces, and without the need to rewrite or 

That sounds like an entirely new requirement that I wouldn't support.

>  It doesn't mean that it wasn't produced by a proper tool.

Correct. I'm still with you. Actually, the code I'm maintaining (SAP's 
WebDAV connector for Netweaver) uses this approach to persist WebDAV 
properties (that may contain arbitrary XML).

> concatenation as long as he can be assured that the default namespace is 

Hm. Even when you think you know your content is well-formed, string 
concatenation may still be dangerous (and that's why I'm not doing it):

- sometimes, you don't have full control about people who write-access 
your store; and they may mess up the otherwise well-formed XML; if 
there's any remote chance that this happens, I'll rather re-parse the 
string instead of ever emitting non-wf XML,

- XML-wellformedness extends to encoding considerations; you may have an 
XML fragment in a string which looks perfectly ok; but emitting it 
inside a different context may still be broken (consider XML that uses 
non-ASCII characters in element names which is serialized in US-ASCII 
encoding)

> feeds, I'm pretty sure that many others do too.

So what does your code when the XML fragment it's pulling from a 
string-based store contains something like:

<ß xmlns="http://julian-reschke.de/julians-funny-xthml-extension>xyz</ß>

Doing this for "arbitrary" content will only fly when the content 
encoding that you may have selected earlier (streaming?) indeed allows 
to serialize all Unicode characters without escaping.

>   <atom:summary xmlns:atom="..." xmlns="...">

Yes (unless xmlns:atom was already declared earlier). That seems like a 
good approach for those who do want the default namespace here.

> are welcome do this, I just don't want to mandate it.

Yes (nor do I).

Yes.

> <atom:summary> and the xhtml fragment that is being syndicated.

So what was wrong with

? The issue here is that your proposal may be the optimla one for those 
who need the default namespace, it's sub-optimal for everybody else.

> to whether there is three or four enclosing feed elements for you to 

Yes. I don't like four :-)

>   1) Graham (who uses proper XML tools) will have to do more work.

Why?

>   2) Tim (who uses string concatenation) will have to do more work.

He can still do what he does. I'll assume that Tim indeed read the draft 
carefully and does what he does entirely on purpose. Why do you think he 
would need to change his code if the spec doesn't change?

>      experiment with alternate serializations.

I think that's a matter of taste. Some prefer less NS declarations, 
other prefer less container elements.

>   3) More feeds will be invalid (content in atom namespace)

On the other hand, more feeds may be invalid because of missing DIV 
elements. It's hard to design a spec for people who don't read it. What 
makes you think that putting a REQUIRED div container element will 
actually force everybody to use it?

>      accurately reflect the content of his entries).

Now you lost me. Are you saying that additional container <div>s affect 
the semantics of XHTML content?

>      via an HTTP POST will end up with multiple <div>s.

If this is the case, the spec possibly should state that container 
<div>s without attributes indeed do not care any additional semantics 
and can safely be collapsed.

>   1) does not require well formed, serialized XHTML fragments to be

Such as...: <atom:summary xmlns:atom="..." xmlns="..."> ?

>      feed "structure" and which are to be considered the "content" being

Yes. So how about instead adding an explanation + example how atom text 
constructs can be serialized in a way such that the XHTML namespace is 
indeed default?

Best regards, Julian

---

From: "Roger B." <[email-masked]>
Date: Thu, 10 Feb 2005 16:11:38 -0600

> That seems like a

Julian: It might actually be the best compromise solution. Advanced
developers will understand what's happening, and View-Sourcers can
copy-n-paste that just as easily as they can copy-n-paste
<summary><div xmlns="..."></div></summary>.

The people left out in this scenario are intermediate developers...
folks who know just enough to find such a construct confusing.  I
suspect Sam would prefer it if all three groups could get something
they can grok, but if that proves impossible, the intermediate folks
may be the ones we can politically afford to fluster.

For what it's worth, I'm still +1 on requiring the <div>. 'Cause
personally, I figure if we're going to inconvenience anyone, it should
be the most advanced among us.

--
Roger Benningfield
JournURL

---

From: James Aylett <[email-masked]>
Date: Fri, 11 Feb 2005 08:54:15 +0000

>      feed "structure" and which are to be considered the "content" being

They're both goals I agree with, but I don't see how <xhtml:div/> can
possibly achieve 2). We're saying "take an element from a /different/
namespace to atom, but treat it as if it weren't part of its children
in the /same/ different namespace; treat it instead as similar to its
own parent, which is in atom's namespace.

That, to me, is totally different to the way namespaces are usually
used (as a kind of mix-in mechanism). Particularly in RSS.

1) breaks down into four cases:

1a)	  people who already have serialised XHTML fragments assuming
	  a default namespace
1b)	  people who already have serialised XHTML, with an explicit
	  namespace on the outermost element of the fragment
1c)	  people who don't have anything, and whose tools will use
	  a default namespace
1d)	  people who don't have anything, and whose tools will use
	  an explicit namespace

If you're using string concatenation (and ignoring character encoding
issues), 1a, 1c lead us to the problem we're trying to solve here; 1b,
1d will be fine whatever we choose.

Can't 1a,1c can be done with treating it all as binary data and
setting the type to HTML (modulo appendix C issues)? Isn't that, in
fact, the only safe way of using string concatenation (modulo encoding
issues, and CDATA ]]> / text node entity escaping issues)? It's what I
took that mode to have been designed for, so why not mandate that
people use it, rather than confuse the issue with an element in one
namespace that must be treated like it's in another?

Of 1c, there will be a small number of
tools-that-have-yet-to-be-written where strong suggestions in the spec
would lead to the authors instead choosing 1d. The rest we're going to
have to live with, somehow.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 10:24:38 +0900

>> Nor am I. The question is what's the best way to enhance the spec. One 
alternative suggestion was made by Martin D$B—S(Bst in 

Fair point.

 >Clear.  Simple.  And difficult to get wrong.

How about the following alternative:

     xhtml:div is not required. xhtml:div is part of the content.

Clear. Simple. And difficult to get wrong :-).

If that's not enough, we can add a note, e.g.:

     Note: A xhtml:div is just an empty wrapper; it will in general
           not affect the processing or display of the content.

Regards,    Martin.