Subject: Re: PaceXhtmlDivSuggestedOnly

From: Thomas Broyer <[email-masked]>
Date: Mon, 02 May 2005 23:27:15 +0200

Antone Roundy wrote:
> I'd support forbidding any attributes other than (a) namespace 
> declaration(s) on container elements...in fact, I'm going to add that 
> to PaceXmlContentWrapper.

Won't that complicate validation a lot?

>> If the spec is changed to forbid any attribute (other than the XHTML 
>> namespace declaration), then the XHTML div is not really an XHTML div,
>>  it becomes (and actually it already is, as it is not part of the 
>> content) a dummy container belonging to the XHTML namespace, whichever
>>  its name (though it's better if it looks like an existing XHTML 
>> element).
> 
> I disagree with this characterization.  We may have profiled the XHTML 
> div element for this particular use, but that doesn't stop it from 
> being an XHTML div.

Honestly, is there a great difference between these two if the 
attributes that are allowed on the container are defined by Atom and no 
more XHTML, apart from "div" looking like an existing XHTML element.

<atom:summary type="xhtml">
   <div xmlns="http://www.w3.org/1999/xhtml">
     Some content <em>here</em>.
   </div>
</atom:summary>

<atom:summary type="xhtml">
   <dummy xmlns="http://www.w3.org/1999/xhtml">
     Some content <em>here</em>.
   </dummy>
</atom:summary>

If you're "profiling" the DIV, you make it different from the XHTML div, 
e.g. a new element with the same name and the same content model.

If you were writing a DTD for Atom (assuming it wouldn't use interleaved 
content models), you'd have to declare your own xhtml:div that would 
shadow the one declared in the XHTMLMOD DTD(s). It would then be obvious 
that *your* xhtml:div is not XHTML xhtml:div but a distinct element with 
the name. And as you probably don't "control" the XHTML namespace, it 
wouldn't be a good design to define a new element in a namespace that is 
not /yours/ .

IMO, embedding XHTML should be done by defining an XHTML content model 
(%Block or %Flow) on a "local" element, such as atom:content, and I 
believe XHTML modularization has been thought and designed this way.

> If the author adds a div or span, that's fine.  But if the software ads 
> it, it's altering the author's content, and should have a way to so 
> indicate so that the change can be undone. 

There are two kinds of Atom document producers:
  - people who create them by hands or code their own application/script 
to build them from their content: these are in the first category: "the 
author adds a div or span".
  - software that is used by authors but is not coded by them. I don't 
think much of these will produce prefix-free Atom documents (although it 
shouldn't be taken in account in the Atom design). Software authors will 
most likely declare the XHTML namespace once (particularly if they treat 
the XHTML as a "black box"), or try to declare it on the content 
elements (if there are paragraphs, on each <p>, if there is only a few 
children in mixed content, on each of these children, etc.). Such 
software shouldn't alter the content in any way.
People using such software (that they have not coded) will most likely 
won't care of how their XHTML (if only they know they are using XHTML!) 
is embedded within their Atom feeds, as long as these feeds are "just 
working". If they do care, well, they'll either find some software that 
adds such a container (so the author is aware that his content will be 
modified) or provide their own container with a namespace declaration 
and find some software that won't try to move this declaration on 
another element.
Finally, people using template-engines, such as MovableType, will choose 
between two kinds of templates (assuming they're using XHTML and MT 
knows how to make an excerpt, essentially closing every opened tag):

<atom:feed xmlns:atom="...Atom NS..."
    xmlns="http://www.w3.org/1999/xhtml">
...
<atom:summary type="xhtml">
<$MTEntryExcerpt$>
</atom:summary>
...
</atom:feed>

and

<feed xmlns:atom="...Atom NS...">
...
<summary type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<$MTEntryExcerpt$>
</div>
</summary>
...
</feed>

Either they use the second one and it's the responsibility of the 
software author/deliverer to inform the end-user that it will wrap his 
content so somehow alter it; or they *choose* between both so it's 
*their* responsibility if their content is altered; or they use the 
first and there's no problem.

I assumed that people who cares about using prefixed-names or 
default-namespaces-only has some minimum technical skill and hence is 
able to either:
  * write their own feeds (or app/template to produce them) the way they
    want; or
  * choose the appropriate application/template that meets their needs

-- 
Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Mon, 2 May 2005 15:42:37 -0600

> Won't that complicate validation a lot?

Not being a validator author, I don't know.  An equally acceptable 
alternative, would be to state that consumers MAY ignore attributes 
other than namespace declarations on contain elements.

>> If the author adds a div or span, that's fine.  But if the software 
>> ads it, it's altering the author's content, and should have a way to 
>> so indicate so that the change can be undone.
>
>  - people who create them by hands or code their own 
> application/script to build them from their content: these are in the 
> first category: "the author adds a div or span".
> think much of these will produce prefix-free Atom documents

Blogger could always change, but right now, they do.  Since it doesn't 
require fiddling with the content as much (the XHTML would still need 
to be validated or at least checked for well-formedness in a robust 
app), I don't think it will be as rare as you're suggesting.