Subject: PaceOptionalXhtmlDiv

From: Thomas Broyer <[email-masked]>
Date: Sat, 14 May 2005 14:15:20 +0200

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

== Abstract ==

Make the XHTML div container optional.

== Status ==

New

== Rationale ==

Make the XHTML div optional but not enforce it to be part of content.

== Proposal ==

Make the following changes to format-08:

=== Section 3.1 ===

Change the {{{atomXHTMLTextConstruct}}} definition to this one: {{{
    atomXHTMLTextConstruct =
       atomCommonAttributes,
       attribute type { "xhtml" },
       (text
        | anyXHTML)*
}}}

=== Section 3.1.1.3 ===

{{{
    If the value of "type" is "xhtml", the content of the Text construct
    MUST be XHTML [XHTML] text and markup that could validly appear within
    an XHTML div element.  Atom Processors which display the content MAY
    use the markup to aid in displaying it.  Escaped characters, such as
    "&" and ">", represent those characters, not markup.

    If the content of the Text Construct is a single XHTML div element
    with no attribute (other than namespace declarations), Atom processors
    SHOULD consider it not being part of the content and discard it. This
    process SHOULD be recursively repeated on the content of the XHTML div.
    Hence, Atom producers MAY enclose the content of the Text Construct
    within such an XHTML div.
}}}

== Impacts ==

People willing to produce prefix-free feeds with "dummy" XHTML 
containers to carry their XHTML namespace decl. can still do so 
'''and''' have these containers not being considered part of the content 
(by some processors).

Producers are allowed to add such dummy containers as well without being 
accused of changing the entry content.

== Notes ==

This Pace is '''not''' incompatible with PaceXhtmlDivSuggestedOnly, at 
least about the inline vs. block content.

If PaceXhtmlDivSuggestedOnly's "inline vs. block content" is adopted, 
this Pace will need updating to allow discarding XHTML "div" and "span" 
elements. I further suggest allowing  to discard any of them 
independently of the Text Construct type (Inline or Block): a div with 
no attribute inside an Inline Text Construct SHOULD be discarded, as 
well as a span with no attribute inside a Block Text Construct.

-- 
Thomas Broyer

---

From: Graham <[email-masked]>
Date: Sat, 14 May 2005 13:52:11 +0100

-1

Misunderstands what the div is for (ie a very elegant solution to a  
difficult problem, with a maximum cost of 11 bytes to those that  
solve the problem in other ways).

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 14 May 2005 16:14:33 +0200

Graham wrote:
> Misunderstands what the div is for (ie a very elegant solution

I totally disagree with "elegant": it's a hack!

> to a  
> difficult problem,

What's difficult?

Namespaces? The spec might add advices and/or examples (like in 
PaceXhtmlDivSuggestedOnly). Namespaces don't seem to me like a 
"difficult problem", moreover if there are feed validators out there.

What else?

> with a maximum cost of 11 bytes

...per XHTML Text Construct and XHTML atom:content, but that's not the 
problem (at least not a great concern for me, but it is for others).

> to those that  solve 
> the problem in other ways).

I might have not be enough explicit in what I'm suggesting with this 
Pace: I just want the XHTML div to be optional for people that don't 
need it but still meeting other people's needs of a "dummy container to 
carry their XHTML namespace declarations".

That way, those two summaries would be equivalent:
<atom:summary type="xhtml"
    xmlns:atom="...Atom NS..."
    xmlns="...XHTML NS...">
       This is a <em>sample</em> summary.
</atom:summary>

<summary type="xhtml" xmlns="...Atom NS...">
    <div xmlns="... XHTML NS...">
       This is a <em>sample</em> summary.
    </div>
</summary>

Would you be >=0 if it where a MUST?

-- 
Thomas Broyer

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 14 May 2005 17:36:52 +0100

>       This is a <em>sample</em> summary.

-1 to PaceOptionalXhtmlDiv.

If we are dealing with systems where a div wrapper is deemed neccessary, 
then you want to take steps to miminise people's options.

For example, PaceOptionalXhtmlDiv will help this to occur:

<summary type="xhtml"
    xmlns:atom="...Atom NS..."
    xmlns="...XHTML NS...">
       This is one busted-ass document - <em>yow!</em>.
</summary>

If you can't trust people not to need the div, then you can't make it 
optional. I unfortunately have a good amount of experience dealing with 
this kind of thing outside Atompub. The simplest answer is to stop the 
'envelope' from using a default namespace (don't bother to debate this 
with me, it's not an imo). We're not doing that with Atom. Failing that, 
the next thing consideration is to add/enforce a protective scoping 
barrier between the envelope and the content. We are doing that with Atom.

[I disagree with Graham btw, and would say xhtml:div is actually 
fighting kluges with kluges, but it works more or less as specified.]

cheers
Bill

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 16 May 2005 00:35:32 +0200

Bill de hÓra wrote:

>> need it but still meeting other people's needs of a "dummy container 
>> to carry their XHTML namespace declarations".
>>
> If we are dealing with systems where a div wrapper is deemed 
> neccessary, then you want to take steps to miminise people's options.

Do you have examples?

div wrappers are necessary only when producers don't want to use 
prefixes. I propose an elegant solution where meaningless wrappers (div 
without any attribute, other than namespace declarations) 
may/should/must be discarded.

Atom processors will always have to deal with namespaces (because I can 
still use prefixes for my Atom and/or XHTML elements, even with the 
format-08 spec) and actually there is no difference at all between 
taking the mixed content inside the XHTML div and taking the mixed 
content inside the atom:content.

So the only difference is on the producers side, and people who don't 
know anything about their XHTML content (and consider it a black box) 
apart from it to be well-formed and use no prefix, those people can 
still use a dummy div wrapper acting just like a "namespace declaration 
carrier".

I don't see the point.

>       This is one busted-ass document - <em>yow!</em>.

Not more than format-08 won't help this not to occur:
<summary type="xhtml"
   xmlns:atom="...Atom NS..."
   xmlns="...XHTML NS...">
<div>
      This is one busted-ass document - <em>yow!</em>.
</div>
</summary>

What will help people who don't know much about XML and namespaces are 
examples and pieces of advice in the spec. And, actually, people who 
don't know much about XML and namespace will probably not read the spec 
but articles published on mass-market web sites...

> optional.

A div (or span) with no attribute has no meaning at all apart from 
grouping content, which is already done by the atom:content; so it can 
be discarded without side effects.

> I unfortunately have a good amount of experience dealing with this 
> kind of thing outside Atompub. The simplest answer is to stop the 
> with me, it's not an imo). We're not doing that with Atom. Failing 
> that, the next thing consideration is to add/enforce a protective 
> scoping barrier between the envelope and the content. We are doing 
> that with Atom.

The first solution is not on the protocol side but on the "producers" 
side: they are responsible of making a well-formed and "valid" document, 
just like they make well-formed and "valid" MS Word, CSV, etc. 
documents, SQL queries, etc.
The second one is on the protocol side.

I don't think such a think have to go on the protocol spec. If hacks 
have to exists to allow prefix-free Atom documents, people wanting them 
will have to find (it's already done) and use them, without bothering 
other people with that.

There will be conforming Atom processors, Atom validators, etc. Such a 
namespace error will show as soon as the Atom document will be 
read/processed by one of them, that is as soon as it will be used. I 
don't expect much people continue producing such documents if they're 
not usable...

-- 
Thomas Broyer

---

From: Martin Duerst <[email-masked]>
Date: Mon, 16 May 2005 18:57:06 +0900

I just had another idea:

Why don't we use a totally different element name, rather than <div>?
What about e.g. <wrapper>? This could be pro-forma in the XHTML Namespace,
but as this isn't handed over to the XHTML rendering engine (as far as
I understand), it wouldn't matter. Also, it would be much easier to
make optional (otherwise we get into the discussion of whether it's
a wrapper div or a real div. Also, it would make things clearer to
people who read the source but not the spec. Other names would of
course be fine, I don't particularly care about a specific one.

So we would have any of the following:

A) No wrapper, none needed, because default namespace set outside

B) No wrapper, none needed, because XHTML has prefix

<atom:summary type="xhtml"
     xmlns:atom="...Atom NS..."
     xmlns:html="...XHTML NS...">
        This is one busted-ass document - <html:em>yow!</html:em>.
</atom:summary>

C) With wrapper

<summary type="xhtml"
     xmlns="...Atom NS...">
<wrapper xmlns="...XHTML NS...">
        This is one busted-ass document - <em>yow!</em>.
</wrapper>
</summary>

If there is some support, I'll write a pace.

Regards,    Martin.

optional. I unfortunately have a good amount of experience dealing with 
this kind of thing outside Atompub. The simplest answer is to stop the 
'envelope' from using a default namespace (don't bother to debate this with 
me, it's not an imo). We're not doing that with Atom. Failing that, the 
next thing consideration is to add/enforce a protective scoping barrier 
between the envelope and the content. We are doing that with Atom.
 >
 >[I disagree with Graham btw, and would say xhtml:div is actually fighting 
kluges with kluges, but it works more or less as specified.]