Subject: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Apr 2005 10:34:10 +0200

Quoting from Andrew Newton's questions relayed by Scott: 
<http://www.imc.org/atom-syntax/mail-archive/msg14048.html>

> From: Andrew Newton [mailto:andy@xxxxxx] 
> Sent: Tuesday, April 05, 2005 6:25 PM
> To: Scott Hollenbeck
> Cc: xml-dir@xxxxxxxx
> Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for
> IETF last call
> 
> 
> ...
> 
> 2) Section 4.1.3.3 Item 2
>    The text:
>      for example, "<br>" as "&lt;br>".
>    Is this right?  Should it be:
>      for example, "<br>" as "&lt;br&gt;".

We don't need to escape the ">" in text content, as far as I can tell. 
Are you suggesting to escape it anyway for consistency/readability?

>    Also, should the "must" in "The HTML markup must be escaped" be a 
> MUST?

I think so.

>    Should rule 2 have the same note regarding the <DIV> element as rule 
> 3?  What happens if the type is html and the content is all within 
> &lt;div&gt; .... &lt;/div&gt; ?

Good question, and an expected one. Lack of consistency here was the 
reason I made the same suggestion (to either do it for both types, or 
not to do for it XHTML).

> ...

I'd like to remind us of another related issue raised a few days ago 
(<http://www.imc.org/atom-syntax/mail-archive/msg14045.html>). XHTML 
content is currently restricted to XHTML Basic (see 
<http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3>, 
<http://www.w3.org/TR/xhtml-basic/>). As far as I can tell, this means 
*no styling*:

- <http://www.w3.org/TR/xhtml-basic/#s1.3.1>: "style" attribute not 
supported (but "class" is), but

- as we require content to be legal within xhtml:div, there's no way to 
specify CSS information.

Although I think it is probably a very good idea to stick with basic 
markup inside the feed, this seems to introduce an unfortunate disparity 
between HTML and XHTML, which will result in

- people ignoring the XHTML Basic restriction, or, even worse,

- people using HTML instead of XHTML to workaround this distinction.

I'd propose to go back to XHTML 1.0 "Strict" instead.

Best regards, Julian

---

From: Martin Duerst <[email-masked]>
Date: Sat, 09 Apr 2005 20:28:40 +0900

>
 >> From: Andrew Newton [mailto:andy@xxxxxx] Sent: Tuesday, April 05, 2005 6:25 PM
 >> To: Scott Hollenbeck
 >> Cc: xml-dir@xxxxxxxx

Correct. From http://www.w3.org/TR/REC-xml/#syntax:
The right angle bracket (>) MAY be represented using the string "&gt;",
and MUST, for compatibility, be escaped using either "&gt;" or a character
reference when it appears in the string "]]>" in content, when that string
is not marking the end of a CDATA section.

I'm slightly surprised to get such a comment from the "XML Directorate".
But I guess their main job isn't to check lowly syntax details.

 >Are you suggesting to escape it anyway for consistency/readability?

Wouldn't be more readable, in my eyes.

(<http://www.imc.org/atom-syntax/mail-archive/msg14045.html>). XHTML 
content is currently restricted to XHTML Basic (see 
<http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3>, 
<http://www.w3.org/TR/xhtml-basic/>). As far as I can tell, this means *no 

 >I'd propose to go back to XHTML 1.0 "Strict" instead.

Very good point. A very strong +1.

Regards,    Martin.

---

From: James Aylett <[email-masked]>
Date: Sun, 10 Apr 2005 10:30:27 +0100

> Wouldn't be more readable, in my eyes.

OTOH since someone has asked the question who presumably is fairly
knowledgable about XML, and most people people are not, would it be
worth putting a brief comment pointing to the appropriate section of
the XML TR?

"Note that in XML the right angle bracket (>) need not be entity
escaped in many common situations. See <REF>."

Or something like that.

James

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

---

From: Tim Bray <[email-masked]>
Date: Sun, 10 Apr 2005 07:40:51 -0700

> escaped in many common situations. See <REF>."

I think this is really extraneous to our spec.  I tend to agree with 
Martin that > is more legible than &gt;, but many software packages 
will always output &gt; because of the small but nonzero possibility of 
something like this happening:

  if (a[b[i]]>0) { c++; } // yer not well-formed

  -Tim

---

From: Norman Walsh <[email-masked]>
Date: Mon, 11 Apr 2005 15:23:54 -0400

[ discussion of basic vs. strict and validity wrt xhtml/html elided ]
|  >I'd propose to go back to XHTML 1.0 "Strict" instead.
|
| Very good point. A very strong +1.

Do we really want to go here? I hadn't interpreted the Atom format
spec as requiring that the content of the xhtml:div be valid according
to any particular schema. If that's our intent, I think this paragraph
needs to be reworded to make that clearer:

 3.  If the value of "type" is "xhtml", the content of atom:content
     MUST be a single XHTML div element
     [W3C.REC-xhtml-basic-20001219].  The XHTML div MUST contain XHTML
     text and markup that could validly appear within an XHTML div
     element.

I don't naturally associate the "MUST" in that last sentence with
"validity" in the sense of "MUST be valid". Perhaps I should.

But I hope not. I don't really want to have to rev the Atom format
spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0
stuff in my xhtml:div elements and let the down-stream appliation work
it out.

At least that's what I think I want.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 11 Apr 2005 15:42:19 -0400

On Apr 11, 2005 3:23 PM, Norman Walsh <[email-masked]> wrote:
> I don't really want to have to rev the Atom format
> spec when XHTML 2.0 comes out. 

+1 

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 11 Apr 2005 21:45:50 +0200

> stuff in my xhtml:div elements and let the down-stream appliation work

XHTML 2 does have a different namespace. Future versions of XHTML may or 
may not have a DIV element. I agree that this might be out the scope of 
Atom, but it does create problems for interoparability.

Also, what do you expect feed readers to support for XHTML versions, etc.

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

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 11 Apr 2005 21:14:09 +0100

> Atom, but it does create problems for interoparability.

It seems to be in scope for Atom because the <{whatever_xhtml_ns}div> 
trick is specified by us (ie it's a solution of our own making).

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Mon, 11 Apr 2005 16:18:27 -0400

/ Anne van Kesteren <[email-masked]> was heard to say:
| Norman Walsh wrote:
|> But I hope not. I don't really want to have to rev the Atom format
|> spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0
|> stuff in my xhtml:div elements and let the down-stream appliation work
|> it out.
|
| XHTML 2 does have a different namespace.

Ouch. I had forgotten or failed to notice that.

Sigh. I'm not sure what to do now. I think it would be nice if Atom 1.0
could work with XHTML 1.0 and 2.0. But that means tinkering a bit with
the language.

| Future versions of XHTML may
| or may not have a DIV element.

In theory, sure, but in practice? HTML isn't likely to lose the
element with the local-name "div" is it, really?

| I agree that this might be out the
| scope of Atom, but it does create problems for interoparability.

Yep.

| Also, what do you expect feed readers to support for XHTML versions, etc.

I don't have any. I'll tailor my content to suit what the major
vendors support, just like I do with my plain old HTML today. In
practice, my feeds contain no markup at all (because I'm still
generating RSS and I will not produce escaped markup).

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The effects of weakness are
http://nwalsh.com/            | inconceivable, and more prodigious than
                              | those of the most violent
                              | passions.--Cardinal De Retz

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 12 Apr 2005 20:45:56 +0300

> stuff in my xhtml:div elements and let the down-stream appliation work

It will be nice to have the div in the XHTML 1.x namespace and the 
contents in the XHTML 2.0 namespace. Namespace div indeed. :-)

But XHTML 2.0 is a different language form XHTML 1.x. Why do you think 
XHTML 2.0 fragments should be allowed as type='xhtml'? Just because 
XHTML 2.0 has "XHTML" in the name? If it is not about the name, why not 
DocBook NG fragments? One might argue that DocBook NG has a better 
chance of getting browser support than XHTML 2.0. ;-)

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

---

From: Tim Bray <[email-masked]>
Date: Tue, 12 Apr 2005 14:21:18 -0700

> could work with XHTML 1.0 and 2.0. But that means tinkering a bit with

We need to do a bit of cleanup.  But bear in mind that the measuring 
stick is interoperability.  In the case of type="html", the language is 
well-taken (from 3.1.1.1):

  If the value of "type" is "html", the content of the Text construct
  MUST NOT contain child elements, and SHOULD be suitable for handling
  as HTML

"suitable for handling as HTML" may be a bit hand-wavy but corresponds 
exactly to reality and is about as far as we can realistically go.  For 
XHTML on the other hand:

  If the value of "type" is "xhtml", the content of the Text construct
  MUST be a single XHTML div element [W3C.REC-xhtml-basic-20001219].
  The XHTML div MUST contain XHTML text and markup that could validly
  appear within an XHTML div element.

First, the word "validly" has to go.  There is little (any?) 
interoperability benefit, but immense costs, in requiring XHTML 
validation.  I suggest rewording to make this congruent with the HTML 
language

  If the value of "type" is "xhtml". the content of the Text construct
  MUST be a single XHTML div element.  The XHTML div must contain XHTML
  1.0 [XHTML traditional reference] text and markup that SHOULD be 
suitable
  for handling as XHTML 1.0 Traditional.

I recommend we use Transitional, since I don't think we should get into 
micro-managing the purity of the payload; but clearly Frameset would be 
going too far. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 12 Apr 2005 18:02:48 -0400

Tim Bray wrote:
> exactly to reality and is about as far as we can realistically go. 

How about this text for XHTML:

  If the value of "type" is "xhtml", the content of the Text construct
  MUST be a single XHTML div element [XHTML transitional reference], and
  SHOULD be suitable for handling as XHTML.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 12 Apr 2005 16:26:08 -0700

>  SHOULD be suitable for handling as XHTML.

+1 --Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 13 Apr 2005 02:18:29 +0200

>   SHOULD be suitable for handling as XHTML.

Good, but I would like us to have the same recommendations in the Atom  
specification as W3C, namely to use a Strict DOCTYPE. How to word this is  
still a bit blurred to me.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 13 Apr 2005 02:24:55 +0200

On Tue, 12 Apr 2005 19:45:56 +0200, Henri Sivonen <[email-masked]> wrote:

> XHTML 2.0 has "XHTML" in the name?

Yes.

> If it is not about the name, why not DocBook NG fragments?

Because "DocBook" does not have "XHTML" in its name, and will not under  
any circumstance cause confusion with Atom using the term "XHTML" as a  
type for content. Since XHTML 1.0 and 2.0 and most likely 2.1, 3.0 and  
whatnot will bear the names "XHTML", we should allow all of them to be  
used in Atom.

Or, we should restrict the allowed XHTML versions in the specification to  
just include 1.x. That leads to different problems, though, since people  
would then think they could use XHTML 1.0 Frameset or XHTML 1.1, which are  
totally different from one another, and will hurt interoperability a great  
deal.

I'd say that we should limit the allowed XHTML versions (including both  
version number and DOCTYPEs) to be used in Atom to XHTML 1.0 Transitional,  
XHTML 1.0 Strict and XHTML 1.1. Since XHTML 2.0 isn't finished yet, it is  
a bit problematic including language about it in the Atom specification,  
so I think we should leave it out at least until it is done. Then we can  
"patch" Atom somehow with an I-D or whatever to include language about  
XHTML 2.0.

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 13 Apr 2005 09:06:59 +0300

>  SHOULD be suitable for handling as XHTML.

Instead of saying "XHTML" it would be clearer to say "XHTML 1.x" or 
defining it in terms of the XHTML 1.x namespace URI.

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

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 13 Apr 2005 09:08:42 +0300

On Apr 13, 2005, at 03:18, Asbjørn Ulsberg wrote:

> namely to use a Strict DOCTYPE.

type='xhtml' takes a fragment and Atom is DTDless. Better to stay away 
from the word DOCTYPE.

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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Apr 2005 14:37:12 +0200

* Henri Sivonen <[email-masked]> [2005-04-13 08:25]:
> > [XHTML transitional reference]
> 
> Instead of saying "XHTML" it would be clearer to say "XHTML
> 1.x" or defining it in terms of the XHTML 1.x namespace URI.

He already did, no?

Regards,
-- 
Aristotle

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Apr 2005 14:39:48 +0200

* Asbjørn Ulsberg <[email-masked]> [2005-04-13 02:35]:
> Or, we should restrict the allowed XHTML versions in the
> specification to  just include 1.x. That leads to different
> problems, though, since people  would then think they could use
> XHTML 1.0 Frameset or XHTML 1.1, which are  totally different
> from one another, and will hurt interoperability a great deal.

Multiple proposals already posted for the wording of this
section suggestion a refererence to the XHTML 1.0 Transitional
spec. That would seem to have preempted this problem.

Regards,
-- 
Aristotle

---

From: Walter Underwood <[email-masked]>
Date: Wed, 13 Apr 2005 07:47:52 -0700

--On April 13, 2005 9:06:59 AM +0300 Henri Sivonen <[email-masked]> wrote:
>
> Instead of saying "XHTML" it would be clearer to say "XHTML 1.x" or defining it
> in terms of the XHTML 1.x namespace URI.

This could work. "XHTML 1.0" will not be confused with a media type.

When XHTML 2.0 is ready, we can add a supplemental RFC which defines
a new attribute value for that.

wunder
--
Walter Underwood
Principal Architect, Verity

---

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

>> 1.x" or defining it in terms of the XHTML 1.x namespace URI.

Not as clearly as possible. If 1.x is meant, it should be clearly 
pointed out. If 1.0 (not Ruby nor the What WG stuff) is meant, it 
should be clearly pointed out.

I prefer 1.x over 1.0 or 2.0.

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

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 13 Apr 2005 20:06:09 +0200

> Ouch. I had forgotten or failed to notice that.

Yeah, using namespaces for versioning sucks...

> element with the local-name "div" is it, really?

Ask Ian Hickson. I believe he is planning to drop it in the WHATWG 
version of XHTML.

> generating RSS and I will not produce escaped markup).

I don't really like this point of view. This is exactly what creates 
interoperability problems and people will blame Atom in the end for 
promising to solve problems it does not.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 13 Apr 2005 15:32:16 -0400

> promising to solve problems it does not.

Atom promised to solve HTML interop issues?

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Wed, 13 Apr 2005 20:31:00 +0100

> promising to solve problems it does not.

I agree that the Atom RFC shouldn't be a moving target.  How about if we:

  Make an IANA registry of Atom Text Types, requiring some level of
  RFC to create new ones.

  Put text, html, and xhtml in the registry, and specify that xhtml
  means XHTML1.0

  Describe what processors should do if they encounter an Atom Text
  Type that they don't understand.

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 13 Apr 2005 22:47:48 +0200

* David Powell <[email-masked]> [2005-04-13 21:50]:
>   Make an IANA registry of Atom Text Types, requiring some
>   level of RFC to create new ones.
> 
>   Put text, html, and xhtml in the registry, and specify that
>   xhtml means XHTML1.0
> 
>   Describe what processors should do if they encounter an Atom
>   Text Type that they don't understand.

This is what I first thought, too. Obviously, the last point of
these points would be the most important, and extra care would
have to be taken not to foul it up.

But is this really a good idea? One aspect I don’t like about
this proposal is that it swaps a fairly important part of Atom
out of the core spec and into a registry, which makes it harder
for first-time implementors to pull together all the pieces
required.

Another aspect is that it seems that it would hurt interop: even
if I know which version of the Atom spec is used by an upstream
producer or expected by a downstream consumer, I can’t know
whether we agree on text types. If support for a set of text
types is inextricably tied to support for a certain version of
the Atom spec, then no ambiguities arise.

A final aspect is that because this is so central to Atom, I
don’t know if it can be guaranteed that updates to the spec will
not require updates in the registry or vice versa. Should that
ever happen, registrations will suddenly have to track which Atom
spec version they are for, or contain multiple definitions to be
chosen from according to Atom version, or some other mechanism,
any form of which will tie registrations and core spec versions
to each other. That negates any gain ever had by separating the
text types out of the core spec.

All in all, I think creating registries is best avoided.

Regards,
-- 
Aristotle

---

From: Graham <[email-masked]>
Date: Wed, 13 Apr 2005 22:10:04 +0100

>   Type that they don't understand.

-1

I think introducing new core data types negates the point of having 
core, well-known data types. XHTML 2.0 is an issue we can solve now.

I think it will be safe to leave any further formats to a new rev of 
the spec, since whatever new thing needs to be added would have to have 
reached similar popularity to either plain text or HTML.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 13 Apr 2005 23:35:35 +0200

> spec. That would seem to have preempted this problem.

Do we really want to exclude XHTML 1.1 as allowed content in Atom  
documents?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 13 Apr 2005 23:34:38 +0200

> type='xhtml' takes a fragment and Atom is DTDless. Better to stay away  

Of course. Still, the allowed elements and attribtues inside the <div> of  
Atom Content constructs is bound to the version of XHTML we choose. And  
the way to identify which version of XHTML you use happens to be done with  
a DOCTYPE and appurtenant DTD (and sadly not an XSD or similar), so I'm  
using it only as a way to identify which versions we are to use, not  
because I want the actual DOCTYPE construct to be allowed within an Atom  
document.

And please note that I have not suggested any form of wording for this  
specification text yet, so this can be formulated however the group finds  
best. I have no proposals for specification text at the moment.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 14 Apr 2005 00:45:52 +0300

>>   Type that they don't understand.

-1 from me as well. Overkill.

> the spec, since whatever new thing needs to be added would have to 
> have reached similar popularity to either plain text or HTML.

That pretty much rules out XHTML 2.0, doesn't it? Good ideas from the 
XHTML 2.0 namespace are being backported to the XHTML 1.x namespace, so 
it is unlikely for XHTML 2.0 to reach large-scale popularity.

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

---

From: Robert Sayre <[email-masked]>
Date: Wed, 13 Apr 2005 17:42:29 -0400

Asbjørn Ulsberg wrote:
>> type='xhtml' takes a fragment and Atom is DTDless. Better to stay 
>> away  from the word DOCTYPE.
> 
> 
> Of course. Still, the allowed elements and attribtues inside the <div> 
> of  Atom Content constructs is bound to the version of XHTML we choose. 

Real world example:

<summary>
   <div xmlns="http://www.w3.org/1999/xhtml"
        xmlns:o="urn:schemas-microsoft-com:office:office">
Dell delivered my replacement 2405FPW today.<span style="">  </span>The 
white line pixel problem had actually disappeared on my first monitor 
when I switched it on the second day, but when a problem has shown 
itself once, who is to say it would not come back.<span style=""> 
</span>I feel better knowing I have a new monitor with zero problems 
from the start.    <p class="MsoNormal">
<!--[if !supportEmptyParas]--> <!--[endif]--><o:p/>
</p>      <p class="MsoNormal">So, now all the problems are over, how is 
the 2405FPW?<span style="">  </span>Outstanding!!!<br/>

<!--[if !supportEmptyParas]--> <!--[endif]--><br/>
   </div>
</summary>

What do we have to say about this?

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Apr 2005 15:19:40 -0700

[[ wearing my IETF weenie hat, not my co-chair hat ]]

>have reached similar popularity to either plain text or HTML.

Fully agree with Graham. IANA registries are mostly for things that 
not core to actually running a spec, and the type of content seems 
quite core.

The "should this be relegated to an IANA registry or not" question 
come up in almost every IETF WG because it is a question of what is 
and is not core for a developer. If a protocol has a reason to have 
lots of registries (such as IPsec, which has a dozen different types 
of transforms), then it is safer to put more core-ish things in a 
registry. But if it has only a few, then we should assume that most 
developers won't bother to look in the IANA registries, greatly 
reducing interoperability for things that appear only in a registry.

I'm fairly certain the Atom format is in the second category.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 14 Apr 2005 04:50:35 +0200

On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre <[email-masked]>  
wrote:

> [snip example]

As far as I can see, the code is valid XHTML 1.0 Strict (and thus also  
both Transitional, Frameset and XHTML 1.1), so I'm not sure what point  
you're making, Robert. Sure, the code is far from pretty, but the validity  
of it is okay.

We can't demand validation or validity in any way, but we can and should  
encourage people to follow W3C's recommendations. And for a long time,  
they have been to code against the strictest DTD possible for the version  
of (X)HTML you are using.

Transitional is a DTD to code against if you're transitioning from invalid  
DOCTYPE-less HTML or HTML 3.2 to valid HTML 4.01 Strict. XHTML 1.0  
Transitional is a mistake, but that discussion is off topic, so I'll leave  
that for now.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 13 Apr 2005 23:37:42 -0400

Asbjørn Ulsberg wrote:
> you're making, Robert. Sure, the code is far from pretty, but the 
> validity  of it is okay.

Thank you, Asbjørn: this is a delightful little problem. You see, XHTML 
validity is specified in terms of DTDs. Near as I can tell, that example 
and some of the XHTML examples in the spec are 'invalid' because the 
local names don't match the DTD, and there are stray xmlns declarations. 
If any of the current versions of XHTML allow that, we should probably 
point to that one, but I don't know if any of them do.

Here's an example of what I mean:
<http://validator.w3.org/check?uri=http%3A%2F%2Ffranklinmint.fm%2F2005%2F04%2F13%2Fhmm.html>

What in the hay are we supposed to reference?

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 14 Apr 2005 06:23:29 +0200

> point to that one, but I don't know if any of them do.

Ah, nice catch. Didn't even think about it, but you're right: Well-formed  
XML is not necessarily valid XHTML.

> What in the hay are we supposed to reference?

That's a very good question I really wished I had an answer to. But right  
now, I don't. :-\

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 14 Apr 2005 09:07:29 +0200 (CEST)

Robert Sayre wrote:
> [snip: an example with mixed XHTML and MicroSoft stuff]
>

Well, I think an XML Schema defined XHTML [1] would allow xmlns
declarations but if you want to include "foreign" elements and attributes
in XHTML, it'll never be valid, except if you write your own XHTML Module
and/or hybrid document type (like the XHTML+MathML+SVG Profile [2]).

However, Atom requires wellformedness, not validity. So your wording, Rob,
>  SHOULD be suitable for handling as XHTML.

The reference should IMHO point to both XHTML 1.0 (allows the lang and
name attributes) and XHTML 1.1 (allows ruby), i.e. having two XHTML
references.

The day XHTML will have an RNG modularized schema (seems to be the case
for XHTML 2.0, but we need XHTML 1.x), Atom would be able to precisely
define (still informative as the Atom RNC schema is not normative) the
content model of the Text Constructs, e.g. extending XHTML with xsd:any
and xsd:anyAttribute (I don't know how to say that in RelaxNG).

[1] http://www.w3.org/TR/xhtml1-schema/
[2] http://www.w3.org/TR/XHTMLplusMathMLplusSVG

-- 
Thomas Broyer

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 14 Apr 2005 13:04:32 +0100

> promising to solve problems it does not.

I don't think is comes under the category of namespaces for versioning 
   problem. We made this problem ourselves, due to the consensus view 
that says default namespaces are so valuable we have the bake an 
inverted dependency into Atom, ie the feature of having to have Atom 
know about XHTML to treat it special is arguably a design problem. And 
our answer to the consequences of the self-made design problem is to 
design a registry?  I don't see that as a simplifying move. If there is 
not a tidy way out of this, or we don't just agree to scope it as a 
point solution for a particular flavour of XHTML, I suggest we revisit 
the xhtml:div approach altogether.

cheers
Bill

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 14 Apr 2005 17:51:20 +0300

> [1] http://www.w3.org/TR/xhtml1-schema/

For the record, James Clark has made Relax NG schemas for some flavors 
of XHTML 1.x. Surely James Clark is at least as good an authority as 
the W3C. :-)

http://www.thaiopensource.com/relaxng/xhtml/

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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 14 Apr 2005 11:52:15 -0600

On Thursday, April 14, 2005, at 06:04  AM, Bill de hÓra wrote:
> know about XHTML to treat it special is arguably a design problem.

Looking at a Blogger-generated Atom 0.3 feed:

<content type="application/xhtml+xml" 
xml:base="http://antone.geckotribe.com/bustedworld/" 
xml:space="preserve">
<div xmlns="http://www.w3.org/1999/xhtml">The package for my son's 
diapers says "22-37 lbs", but there is <i>absolutely no way</i> they 
could hold that much stuff without leaking!</div>
</content>

...so we certainly didn't create the problem by requiring the 
div--xmlns attributes were being added to <div>s in Atom feeds before 
we came up with the idea.  What we've discovered is that there is no 
way to make the XHTML namespace the default namespace while having the 
content be a valid XHTML fragment.  We'd have to allow the <html> 
element inside of atom:content to do that.  Other options include not 
worrying about whether the content is valid XHTML (though of course it 
must be well-formed XML), or only requiring that the content of the div 
be a valid XHTML fragment, and not the div itself, which, since the div 
isn't part of the content, wouldn't be entirely strange.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 14 Apr 2005 20:38:32 +0200

Henri Sivonen wrote:
> of XHTML 1.x. Surely James Clark is at least as good an authority as the 
> W3C. :-)
> 

So Atom could propose a Relax NG schema that could validate the included 
XHTML as well!
And as the Atom Relax NG schema is not normative and the text would say 
the content SHOULD be "valid" XHTML, if one want to use invalid XHTML, 
his feed is still valid Atom.

If I understand RNG and RNC correctly, the schema would say something like:

include http://www.thaiopensource.com/relaxng/xhtml/modules/text.rng {
    Inline.class |= element * - atom:* - xhtml:*
    Block.class  |= element * - atom:* - xhtml:*
    Core.attrib  &= attribute * - atom:* - xhtml:* { text }*
}

# Include here every other needed XHTML schema
# should be all except struct.rng and frames.rng, and evenly legacy.rng

# define the xhtmlDiv used by Text Constructs and atom:content
# it might be needed to redefine allowed attributes

xhtmlDiv = xhtml:div

# if we want to get rid of the div wrapper, use sth like that instead:
# xhtmlDiv = div.attlist, Flow.model

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Thu, 14 Apr 2005 15:07:30 -0400

Bill de hÓra wrote:

> If there is not a tidy way out of this, or we don't just agree to
> scope it as a point solution for a particular flavour of XHTML, I
> suggest we revisit the xhtml:div approach altogether.

Bill, I don't think the problem is exclusive to the outer div. I can't 
find any version of XHTML that allows <xh:p/> where xh is bound to the 
XHTML namespace URI.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 14 Apr 2005 22:10:54 +0100

Antone Roundy wrote:
> xml:base="http://antone.geckotribe.com/bustedworld/" xml:space="preserve">
> ...so we certainly didn't create the problem by requiring the div--xmlns 
> attributes were being added to <div>s in Atom feeds before we came up 
> with the idea.  What we've discovered is that there is no way to make 
> the XHTML namespace the default namespace while having the content be a 
> valid XHTML fragment.  We'd have to allow the <html> element inside of 
> atom:content to do that.  Other options include not worrying about 
> whether the content is valid XHTML (though of course it must be 
> well-formed XML), or only requiring that the content of the div be a 
> valid XHTML fragment, and not the div itself, which, since the div isn't 
> part of the content, wouldn't be entirely strange.

I didn't follow that Antone, sorry, but... until I understand what 
you're saying, I'll hold my position that an enveloping format like Atom 
having  to special case XHTML payloads is design problem because the 
dependencies are travelling in the wrong direction. XHTML in the wild 
notwithstanding if we spec it in, it's our problem. I do take what into 
account what Robert said about XHTML and prefixes, btw, but I wonder how 
much of this goes away if Atom does not use default namespaces. And 
while I do realize that XML in XML tends be a broader problem that just 
Atom, one counter-example on prefixed Atom+XHTML not working would 
probably shut me up.

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Thu, 14 Apr 2005 15:58:05 -0600

On Thursday, April 14, 2005, at 03:10  PM, Bill de hÓra wrote:
>> way to make the XHTML namespace the default namespace while having 
>> the content be a valid XHTML fragment.  We'd have to allow the <html> 
>> worrying about whether the content is valid XHTML (though of course 
>> it must be well-formed XML), or only requiring that the content of 
>> the div be a valid XHTML fragment, and not the div itself, which, 
>> since the div isn't part of the content, wouldn't be entirely >> strange.
>
> I didn't follow that Antone

I'll see if I can be more clear on the points I was making:

1) Blogger-generated Atom 0.3 feeds, which predate the requirement to 
have an xhtml:div inside atom:content when @type="xhtml" have an xmlns 
attribute (which is not "valid" in xhtml).  So the div requirement 
didn't create the problem of people putting invalid XHTML fragments 
into atom:content as had been asserted.

2) Because xhtml:div in valid XHTML can't have an xmlns attribute 
(that's what started this whole discussion, right?), the XHTML 
namespace has to be declared on or outside of atom:content--it can't be 
declared inside of atom:content--unless we don't care that the contents 
of atom:content are not valid XHTML.  Note the following two excerpts 
from http://www.w3.org/TR/xhtml1/#well-formed, which legitimize doing 
exactly what's being done in Atom 0.3...just with <p> instead of <div>:

===================

The XHTML namespace may be used with other XML namespaces as per 
[XMLNS], although such documents are not strictly conforming XHTML 1.0 
documents as defined above.

===================

...of course, we're not trying to create "strictly conforming XHTML 1.0 
documents", we're creating Atom documents with XHTML 1.0 fragments 
embedded in them.

===================

The following example shows the way in which XHTML 1.0 markup could be 
incorporated into another XML namespace:

<?xml version="1.0" encoding="UTF-8"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
     xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
   <title>Cheaper by the Dozen</title>
   <isbn:number>1568491379</isbn:number>
   <notes>
     <!-- make HTML the default namespace for a hypertext commentary -->
     <p xmlns='http://www.w3.org/1999/xhtml'>
         This is also available <a href="http://www.w3.org/">online</a>.
     </p>
   </notes>
</book>

===================

3) I erred in my earlier assertion that this makes it impossible to 
make the XHTML namespace the default namespace, but it makes it sloppy. 
  Examples of how it could be done:

<atom:feed xmlns:atom="our namespace URI" xmlns="XHTML's namespace URI">
...
<atom:content type="XHTML">
<div>This is XHTML content,<br />
and the default namespace is XHTML's.</div>
</atom:content>

or

<feed xmlns="our namespace URI">
...
<atom:content type="XHTML" xmlns:atom="our namespace URI" 
xmlns="XHTML's namespace URI">
<div>This is XHTML content,<br />
and the default namespace is XHTML's.</div>
</atom:content>

4) Another option (which I would NOT be in favor of) would be to allow 
xhtml:html in atom:content, since xhtml:html CAN have an xmlns 
attribute.  For example:

<feed xmlns="our namespace URI">
...
<content type="XHTML">
<html xmlns="XHTML's namespace URI">
<head />
<body>
<div>This is XHTML content,<br />
and the default namespace is XHTML's.</div>
</body>
</html>
</content>

> I do take what into account what Robert said about XHTML and prefixes
I'm not sure which comment you're referring to.  The one comment I 
found, I had interpreted to mean that in XHTML, <p> can't be empty, as 
in <p /> (http://www.w3.org/TR/xhtml1/#h-4.3 : "All elements other than 
those declared in the DTD as EMPTY must have an end tag. Elements that 
are declared in the DTD as EMPTY can have an end tag or can use empty 
element shorthand").  If the point was that XHTML requires the XHTML 
namespace to be the default, then I was unable to find any place where 
that was specified.

> but I wonder how much of this goes away if Atom does not use default 
> namespaces.
Perhaps all of it.  But I'm still emotionally attached to default 
namespaces.  ;-)

Antone

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 15 Apr 2005 00:00:33 +0200

Robert Sayre wrote:
> I can't find any version of XHTML that allows <xh:p/> where xh is
> bound to the XHTML namespace URI.

<!DOCTYPE xh:div PUBLIC "-//W3C//DTD XHTML 1.1//EN" [
    <!ENTITY % NS.prefixed  "INCLUDE">
    <!ENTITY % XHTML.prefix "xh">
]>
<xh:div xmlns:xh="http://www.w3.org/1999/xhtml" xml:lang="en">
   This does not a strictly conforming XHTML 1.1 document as defined in
   <xh:a href="http://www.w3.org/TR/xhtml11/conformance.html#strict">
   XHTML 1.1, section 2.1.1. Strictly Conforming Documents</xh:a> but it
   <xh:strong>is</xh:strong> a valid XML document, using the XHTML 1.1
   DTD.
</xh:div>

...and this is the case only when validating against a DTD. Validating 
against the XML Schema [1] will allow any kind of prefix to be bound to 
the XHTML namespace:

<x:div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.w3.org/1999/xhtml
            http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd">
   This document is valid against the <x:a title="W3C Note: XHTML 1.0 in
   XML Schema" href="http://www.w3.org/TR/xhtml1-schema">XHTML 1.0 XML
   Schema</x:a>, without any trickery.
</x:div>

I believe the same thing happens (no needed trickery) when using a Relax 
NG schema, like the ones by James Clark.

-- 
Thomas Broyer

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 15 Apr 2005 00:07:56 +0200

Antone Roundy wrote:
> What we've discovered is that there is no way to make the XHTML 
> namespace the default namespace while having the content be a valid 
> XHTML fragment.  We'd have to allow the <html> element inside of 
> atom:content to do that.

Even if you were allowing the html element inside atom:content, it
wouldn't be "valid XHTML":
  - it is not a Strictly Conforming Document [1] since the html element
    is not the root element (it's a child of atom:content)
  - neither it is a valid XML document since Atom doesn't provide a DTD

[1] http://www.w3.org/TR/xhtml1/#strict

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Thu, 14 Apr 2005 18:39:50 -0400

> Atom, one counter-example on prefixed Atom+XHTML not working would 

I'm not looking to shut you up, but I thought I'd do some experiments.

The two feeds below are identical (save atom:id). They each contain two 
entries with equivalent content, except one entry has prefixed XHTML 
content. You should see bold and italics in the content of both entries. 
The prefixed content doesn't work in Bloglines... :/

Here you go, folks:

Atom 0.3 served as text/xml:
http://www.franklinmint.fm/2005/04/14/prefixtest.xml

Atom 0.3 served as application/atom+xml:
http://www.franklinmint.fm/2005/04/14/prefixtest.atom

Some html, just for fun:

XHTML served as text/html:
http://www.franklinmint.fm/2005/04/14/prefixed.html

XHTML served as application/xhtml+xml:
http://www.franklinmint.fm/2005/04/14/prefixed.xhtml

Robert Sayre

---

From: Graham <[email-masked]>
Date: Fri, 15 Apr 2005 00:23:38 +0100

On 14 Apr 2005, at 11:39 pm, Robert Sayre wrote:

> The two feeds below are identical (save atom:id). They each contain 
> two entries with equivalent content, except one entry has prefixed 
> XHTML content. You should see bold and italics in the content of both 
> entries. The prefixed content doesn't work in Bloglines... :/

I'd suggest that's because Bloglines is broken, and that we need a 
prefixed example in the spec.

(Disclosure: Shrook is also broken in this regard, but it will be fixed 
for Atom 1.0)

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 15 Apr 2005 10:14:06 +0200

On Thu, 14 Apr 2005 23:58:05 +0200, Antone Roundy <[email-masked]>  
wrote:

> <atom:content type="XHTML" xmlns:atom="our namespace URI" xmlns="XHTML's  
> namespace URI">

This example made me think about another solution for the Content  
Constructs of Atom. Today, they all reside in the Atom namespace, which of  
course, makes most sense. But even though I see it is a major hack, won't  
putting Content Constructs inside the target namespace of the embedded  
content be a solution to tell what type of content we are embedding  
without having to use a 'type' element? Example:

   <feed xmlns="atom ns">
     ...
     <content xmlns="http://www.w3.org/1999/xhtml">
       <h1>Booyah! This is an XHTML fragment.</h1>
     </content>
   </feed>

Since Atom consumers need to have special handling for each 'type'  
('html', 'xhtml', 'text') we provide today, we might as well imho signify  
this with the XHTML namespace as with a 'type' attribute. The problem is  
that it's difficult to say «this is to be parsed as escaped SGML» in  
contrary to «this is to be read as plain text». Alas, we need a solution  
for non-XML types in Atom if we think using namespaces is a good enough  
solution for XML types.

If we take the hack even further, we could create pseudo namespaces for  
text and HTML types as well. Or perhaps even a general SGML namespace. So  
when we want to embed text in Content Constructs, we do it like this:

   <content xmlns="atom ns#text">
     *Booyah! This is an text fragment.*
   </content>

And when we want to embed HTML, we do it like this:

   <content xmlns="atom ns#html">
     &lt;h1&gt;Booyah! This is an text fragment.&lt;/h1&gt;
   </content>

I've already mentioned that I think this solution is a hack, and I'm not  
sure I like it, but what I do like about it is that it gives us a general  
way to deal with XML content that is much simpler (imho at least) than any  
other previous solution (which have included 'type', 'mode' and various  
other attributes).

Yes, there is no element called 'xhtml:content' in the XHTML  
specification, but we won't have _valid_ (although wellformed) XHTML in  
Atom anyways, so why strive so hard to reach something we won't reach  
anyway? The XHTML content in Atom will be valid XML. It can't ever be  
valid XHTML. Let's just settle with that and move forward, no?

---

From: Antone Roundy <[email-masked]>
Date: Fri, 15 Apr 2005 09:11:39 -0600

On Friday, April 15, 2005, at 02:14  AM, Asbjørn Ulsberg wrote:
> But even though I see it is a major hack, won't putting Content 
> Constructs inside the target namespace of the embedded content be a 
> solution to tell what type of content we are embedding without having 
> to use a 'type' element?

I think we're better off sticking with the solution suggested in the 
XHTML spec, where the XHTML namespace is declared on the top level 
XHTML element.  Unlike their example, <div> is a better element to use 
there than <p> (if we wish to standardize on one), because the content 
may contain multiple paragraphs, and <div> can encompass multiple 
paragraphs.  Finally, *requiring* the div and specifying that it's not 
to be treated as part of the content clarifies what would otherwise be 
the ambiguous status of the outermost element inside atom:content.

Note that for other XML types, things are still ambiguous:

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

So we don't know whether we have a full document or a fragment, nor 
whether the outermost child element (if there IS only one) is a 
throwaway container or a keeper.  An idea that just popped into my head 
would be to add one attribute to atom:content (and perhaps text 
constructs) to specify how to handle XML content...don't we just love 
adding new attributes!  For example (pulling a name out of the air):

<content type="xhtml" container="dispose">
	<div xmlns="http://www.w3.org/1999/xhtml">
		This is XHTML content in a throwaway div.
		Any attributes on that div that aren't handled by the XML processor 
are at risk of being lost,
			so adding styles there, for example, is not a good idea.
		Depending on the XML processor the consumer uses, things like 
xml:lang may be preserved,
			but it would probably be wiser to put those elsewhere,
			on an element that isn't getting thrown away.
	</div>
</content>

<content type="xhtml" container="keep">
	<div xmlns="http://www.w3.org/1999/xhtml" style="color:#c00;">
		This is XHTML content in a div which IS part of the content.
	</div>
</content>

<content type="xhtml" container="none" 
xmlns:xh="http://www.w3.org/1999/xhtml">
	<xh:p>This is the first paragraph of XHTML content with no container 
element inside atom:content.</xh:p>
	<xh:p>This is the second paragraph.</xh:p>
</content>

Actually, "keep" and "none" would be processed identically--both treat 
everything inside atom:content as part of the content--so "none" could 
be used in both places.

Arguments could be made for making either the default:

Dispose:
	* Requires no changes to Atom feeds based on the current draft.
	* Requires no changes to Atom feeds following the current convention 
of putting XHTML content into a container div that appears to be 
getting added during serialization.

None:
	* Arguably more precise for non-XML content (they don't have a 
container, so "dispose" would have to be interpreted as "if there IS an 
immediate child element, dispose of it" to exactly make sense).
	* Doesn't require action based on a non-specified attribute--you only 
dispose of something if explicitly told to do so.

Hmm, I just noticed that I didn't create an example for differentiating 
between fragments and complete documents, but offhand, that doesn't 
feel necessary.

Antone

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 15 Apr 2005 20:12:55 +0200

> and the default namespace is XHTML's.</div>

I like this. A lot.

* Asbjørn Ulsberg <[email-masked]> [2005-04-15 10:20]:
> Example:
> […]
> If we take the hack even further, we could create pseudo
> namespaces for  text and HTML types as well.

Ugh, no. @xmlns has well-defined meaning. I don’t think we should
be overloading it this way.

It seems to me that it would be best to just state that
atom:content MAY have a @type whose value is 'text', 'html', or
'xml'. If absent it defaults to 'xml', and wWhen the effective
value is 'xml', atom:content MUST contain XML data. What kind of
data that is need not be further specified; it is determined by
the namespace that the data is in. The approach proposed by
Antone Roundy would be shown in the examples in the spec.

That would get rid of one of the special cases.

Regards,
-- 
Aristotle

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 15 Apr 2005 22:30:44 +0200

> > and the default namespace is XHTML's.</div>

One better, with my @type='xml' suggestion instead of
@type='xhtml':

    <feed xmlns="atom-ns-uri" xmlns:atom="atom-ns-uri">
        <!-- ... -->
        <atom:content type="xml" xmlns="http://www.w3.org/1999/xhtml">
            <p>This is XHTML content.</p>
            <p>The default namespace is XHTML's.</p>
        </atom:content>
        <!-- ... -->
    </feed>

That gets rid of the need to declare the atom: prefix over and
over.

Regards,
-- 
Aristotle

---

From: Antone Roundy <[email-masked]>
Date: Fri, 15 Apr 2005 14:53:12 -0600

>     <feed xmlns="atom-ns-uri" xmlns:atom="atom-ns-uri">

While this approach has it's appeal, I'm pretty sure I'm in favor of 
keeping "xhtml" as a special case for a few reasons:

1) I presume ("when you presume you make a pres of you and me"?) that 
XHTML is going to be by far the most common XML type used in 
atom:content, and least for a while.

2) It makes it more difficult to determine the type of data.  We know 
it's XML, but to find out whether it's a flavor of XML that we know how 
to deal with, we have to discover the namespace of the content.  That 
will sometimes be easy to determine, as in the example above, because 
the namespace is declared on the content element.  However, sometimes, 
it may be done like this:

     <feed xmlns="atom-ns-uri" xmlns:xhtml="xhtml-ns-uri">
         <!-- ... -->
         <content type="xml">
             <xhtml:p>This is XHTML content.</xhtml:p>
             <xhtml:p>The default namespace is XHTML's.</xhtml:p>
         </content>
         <!-- ... -->
     </feed>

In this case, we'd have to find a child element and check it's 
namespace.  We've already discussed and rejected the idea of requiring 
namespaces to be declared at a particular point in Atom documents, so I 
think requiring to be declared in atom:content to make the type 
discovery easy has already been rejected.

The alternative would be to use the full MIME type instead of just 
"xml" and use that instead of the namespace to discover the type.  But 
there's still a problem...

3) Some people are still going to do it the way it's being done now, 
leaving us with the ambiguous status of the div.  Is it part of the 
content or just a container?

Antone

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 15 Apr 2005 23:51:58 +0200

* Antone Roundy <[email-masked]> [2005-04-15 23:05]:
> 2) It makes it more difficult to determine the type of data.
> We know it's XML, but to find out whether it's a flavor of XML
> that we know how to deal with, we have to discover the
> namespace of the content.

Good point, but it can be addressed. Bear with me, because this
is going to get a bit long; but I believe my idea yields an
elegant solution, eventually.

Including the full MIME type is cruft, IMHO, in that it
duplicates information that is already there.

How about saying that the namespace associated with a particular
prefix on the atom:content element level is to be consulted for
the type of the content? In the simpler case, this could be
supplied as an extra attribute, say @ns. The default namespace
could be referred to using the special value '#default' (see XSLT
for prior art), yielding something like

    <feed xmlns="atom-ns-uri" xmlns:a="atom-ns-uri">
        <!--...-->
        <atom:content xmlns="xhmlt-ns-uri" ns="#default">
            <p>Hello, world.</p>
        </atom:content>
        <!--...-->
    </feed>

@ns here says that the namespace bound to the xh: prefix which is
in effect from the atom:content element is to be considered the
type of the content. Since the default namespace declared in situ
applies to the atom:content element itself, and the default
namespace is bound to the XHTML namespace URI, the content is
XHTML.

This means the following is possible just as well:

    <feed xmlns="atom-ns-uri" xmlns:xh="xhtml-ns-uri">
        <!--...-->
        <content ns="xh">
            <xh:p>Hello, world.</xh:p>
        </content>
        <!--...-->
    </feed>

Again, @ns says that the namespace bound to the xh: prefix which
is in effect from the atom:content element is to be considered
the type of the content. It is easier to see in this case that
indeed that is XHTML.

Finally, we can define @ns to have a default value of '#default',
in which case a lot of people will not need to use @ns at all:

    <feed xmlns="atom-ns-uri" xmlns:atom="atom-ns-uri">
        <!--...-->
        <atom:content xmlns="xhmlt-ns-uri">
            <p>Hello, world.</p>
        </atom:content>
        <!--...-->
    </feed>

The only ones who need to be particularly careful then are those
who create new feeds from existing feeds: they need to be careful
to assign appropriate values for @ns attributes rather than just
copying them thru blindly. This is not difficult; the necessary
tools exist in XSLT/XPath, f.ex.

> 3) Some people are still going to do it the way it's being done
> now, leaving us with the ambiguous status of the div.  Is it
> part of the content or just a container?

Is that really a great concern? Both semantically and
presentionally, xhtml:div is neutral, so considering it
to be part of the content does not change its interpretation.
Thus, I don’t see any harm in eliding the issue altogether.

Regards,
-- 
Aristotle

---

From: Antone Roundy <[email-masked]>
Date: Fri, 15 Apr 2005 16:32:58 -0600

...
> duplicates information that is already there.

Not for non-XML data types, which don't have namespaces.

> supplied as an extra attribute, say @ns.

...which "duplicates information that's already there."

> tools exist in XSLT/XPath, f.ex.

...which not everyone is going to be using.  Copying and pasting @type 
will be easy for everyone.

> Thus, I don’t see any harm in eliding the issue altogether.

This question has been discussed before, and the group is divided on 
it.  Actually, it's not presentationally neutral.  Consider the 
difference between these:

<a href="http://www.example.com/">This is the entry title</a>
This is the entry content.

<a href="http://www.example.com/">This is the entry title</a>
<div>This is the entry content.</div>

In the first, the content is displayed inline, and thus the line 
doesn't break after the link.  In the second, there's a linebreak.

See also http://www.imc.org/atom-syntax/mail-archive/msg13535.html

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 17 Apr 2005 11:47:39 +0300

> find any version of XHTML that allows <xh:p/> where xh is bound to the 

DTDs and namespaces are inherently incompatible. I think the 
restrictions the official DTDs place on namespace declarations should 
be ignored when embedding XHTML in Atom. (Note that the XHTML 
Modularization DTDs have stuff that can be parametrized.)

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

---

From: David Powell <[email-masked]>
Date: Sun, 17 Apr 2005 10:53:57 +0100

Sunday, April 17, 2005, 9:47:39 AM, Henri Sivonen wrote:

> be ignored when embedding XHTML in Atom.

I strongly agree. Namespaces are a pretty fragile technology; any
solution that requires micro-management of namespace declarations is
going to be even more fragile.

As far as I know, XSLT and many XML APIs don't have any control over
the position of namespace declarations. We shouldn't be forcing
publishers to use printf to generate Atom.

-- 
Dave