Subject: Forward Compatibility

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 19 Nov 2006 00:16:51 +0800

I am sorry that I have sent an e-mail in HTML format. This is the plain text version, which has the same contents with the HTML version sent before.

Currently, there is no "version" element or attribute to reflect the current version of Atom using in an Atom feed. Does it mean that there will not be any new version of Atom?

On the other hand, the specification mentioned “If the value of "type" is "xhtml", the content of atom:content MUST be a single XHTML div element and SHOULD be suitable for handling as XHTML.”. At the moment, both XHTML 1.0 and 1.0 are sharing the same XML Namespace of "http://www.w3.org/1999/xhtml". However, XHTML 2.0 will have a new namespace "http://www.w3.org/2002/06/xhtml2/", and the chance of having more future versions of XHTML cannot be eliminated. Have Atom prepared for this?

Franklin Tse

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 18 Nov 2006 10:53:06 -0800

On 2006/11/18, at 8:16 AM, Tse Shing Chi ((Franklin/Whale)) wrote:

> Currently, there is no "version" element or attribute to reflect  
> the current version of Atom using in an Atom feed. Does it mean  
> that there will not be any new version of Atom?

Atom has a namespace; that can be use to introduce new versions of  
the format. That said, a new version of Atom itself should only be  
necessary if a fundamental bug or limitation is found in the  
specification of the feed itself, or in required element-level  
metadata; new metadata can be added using extensions, rather than by  
versioning Atom.

> However, XHTML 2.0 will have a new namespace "http://www.w3.org/ 
> 2002/06/xhtml2/", and the chance of having more future versions of  
> XHTML cannot be eliminated. Have Atom prepared for this?

This was intentional; if we allowed future, non-backwards compatible  
versions of HTML to appear in the same places that XHTML1 content is  
allowed, processors wouldn't know what to do with it unless they  
understood XHTML2. Tying the allowed content to a specific version of  
XHTML promotes interoperability.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Sat, 18 Nov 2006 11:19:40 -0800

Mark Nottingham wrote:
> [snip]
> ...new metadata can be added using extensions, rather than by versioning Atom.

It's also possible for new RFC's to update the current Atom namespace in
a backwards compatible way without deprecating/obsoleting RFC4287.

>> However, XHTML 2.0 will have a new namespace
>> "http://www.w3.org/2002/06/xhtml2/", and the chance of having more
>> future versions of XHTML cannot be eliminated. Have Atom prepared for
>> this?
> 

That said, Atom can currently carry XHTML2 by specifying the media type
and properly declaring the namespace.

- James

---

From: Elliotte Harold <[email-masked]>
Date: Sat, 18 Nov 2006 14:46:16 -0500

Mark Nottingham wrote:

> Atom has a namespace; that can be use to introduce new versions of the 
> format. 

No, no, and no. We've been down this road before in other specs, and the 
  community wisdom is that you do not rev the namespace just to 
introduce a new version. Doing so breaks a huge amount of the existing 
processing chain for an application.

It is, of course, possible to introduce new elements in other 
namespaces; and the Atom spec does a much better than average job of 
preparing for this. Indeed there are already many interesting extensions.

However, even if fundamental flaws were found in Atom 1.0 that required 
revisions and an Atom 1.1 or 2.0, the namespace should and almost 
certainly woulds remain the same.

-- 
Elliotte Rusty Harold  [email-masked]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

---

From: Nikola Stojanovic <[email-masked]>
Date: Sat, 18 Nov 2006 15:06:35 -0500

> certainly woulds remain the same.

Very Interesting. What would then be the purpose of "2005" in the atom 
namespace xmlns:atom="http://www.w3.org/2005/Atom"?

Regards,
Nikola

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 18 Nov 2006 21:48:30 +0100

* Elliotte Harold <[email-masked]> [2006-11-18 21:00]:
> Mark Nottingham wrote:
> >Atom has a namespace; that can be use to introduce new
> >versions of the format. 
> 
> No, no, and no. We've been down this road before in other
> specs, and the community wisdom is that you do not rev the
> namespace just to introduce a new version. Doing so breaks
> a huge amount of the existing processing chain for an
> application.
> 
> namespaces; and the Atom spec does a much better than average
> job of preparing for this. Indeed there are already many
> interesting extensions.
> 
> However, even if fundamental flaws were found in Atom 1.0 that
> required revisions and an Atom 1.1 or 2.0, the namespace should
> and almost certainly woulds remain the same.

Yes and no.

If future changes can be made in a backward-compatible
fashion, they will go into a spec that recycles the same
namespace. Existing implementations can just ignore the
differences.

If they cannot, they will go into a spec which revs the
namespace, because trying to process documents conforming
to the new spec with existing implementations can’t work.

In neither case is there a need to identify the version
explicitly.

This is why Atom does not have a version attribute.

All that said, the goal during development was always that
Atom would ship when it was done and be stable thereafter.
It is now set in stone for the forseeable future. No further
development of the core format is expected. (Instead, the
spec includes a number of extension points that can be used
to repurpose the format to new use cases.)

This is another reason why Atom does not have a version
attribute.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Henri Sivonen <[email-masked]>
Date: Sat, 18 Nov 2006 23:13:27 +0200

On Nov 18, 2006, at 22:06, Nikola Stojanovic wrote:

> What would then be the purpose of "2005" in the atom namespace  
> xmlns:atom="http://www.w3.org/2005/Atom"?

It indicates the year when the URI was minted. It is debatable  
whether it is a useful purpose, but that's the way the W3C mints URIs.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 18 Nov 2006 16:19:46 -0800

At 9:48 PM +0100 11/18/06, A. Pagaltzis wrote:
>to the new spec with existing implementations can't work.

Exactly right.

>This is another reason why Atom does not have a version

+1

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 19 Nov 2006 10:33:39 +0800

This means that XHTML 2 contents can be used as follows?

<content type="xhtml">
  <div xmlns="http://www.w3.org/2002/06/xhtml2/">
    <!-- Contents XHTML 2.0 -->
  </div>
</content>

<content type="application/xhtml+xml">
  <div xmlns="http://www.w3.org/2002/06/xhtml2/">
    <!-- Contents XHTML 2.0 -->
  </div>
</content>

By the way, are they the same?

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M Snell
Sent: Sunday, November 19, 2006 03:20
To: Mark Nottingham
Cc: Tse Shing Chi ((Franklin/Whale)); [email-masked]
Subject: Re: Forward Compatibility

- James

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 19 Nov 2006 11:44:41 +0800

Actually, all XHTML 1.0, 1.1 and 2.0 are members of the XHTML family. They, of course, can be carried by type="application/xhtml+xml". But it is quite confusing that type="xhtml" must be XHTML 1.0 or 1.1.

Franklin

-----Original Message-----
From: James M Snell [mailto:[email-masked]] 
Sent: Sunday, November 19, 2006 11:30
To: Tse Shing Chi (Franklin/Whale)
Subject: Re: Forward Compatibility

>     <!-- Contents XHTML 2.0 -->

Not this one.  When type="xhtml" you must use XHTML 1.0 or 1.1

>     <!-- Contents XHTML 2.0 -->

This should be fine.

- James

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 19 Nov 2006 11:42:57 +0200

> By the way, are they the same?

They are not the same and neither is correct. The correct way would be:

<content type="application/xml">
   <html xmlns="http://www.w3.org/2002/06/xhtml2/">
     <head>
       <title>The title of the entry again</title>
     </head>
     <body>
       <!-- Contents XHTML 2.0 -->
     </body>
   </html>
</content>

But it isn't worthwhile to spend energy on this issue. Browser  
vendors have been ignoring XHTML 2.0 and now even the W3C itself is  
moving aside the group that has been working on the XHTML 2.0 spec.

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

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 19 Nov 2006 18:10:24 +0800

First of all, the media type should still be "application/xhtml+xml" for XHTML 2.0, although application/xml or even text/html may be used.

I don't think whole XHTML 2.0 document needs to be contained in the content or summary element, it is too complicated. Using the div element is still a suitable way (div is remained in XHTML 2.0 without major changes, http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structural_div) I think.

For browsers' implementation, in fact, XHTML 1.1 is still not well-supported. CSS 2 is another example of poor implementation by browsers. I do think that Atom should not be easy to change or be updated very frequently. That's why Atom should leave some extents of forward compatibility.

Franklin

-----Original Message-----
From: Henri Sivonen [mailto:[email-masked]] 
Sent: Sunday, November 19, 2006 17:43
To: Tse Shing Chi ((Franklin/Whale))
Cc: Atom Syntax
Subject: Re: Forward Compatibility

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

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 19 Nov 2006 16:49:20 +0200

On Nov 19, 2006, at 12:10, Tse Shing Chi ((Franklin/Whale)) wrote:

> First of all, the media type should still be "application/xhtml 
> +xml" for XHTML 2.0, although application/xml or even text/html may  
> be used.

RFC 3236 makes it pretty clear that it is for XHTML Family documents  
in the Modularization of XHTML sense. XHTML 2.0 documents are not  
XHTML Family documents. They are incompatible documents with a  
confusing name.

> I don't think whole XHTML 2.0 document needs to be contained in the  
> content or summary element, it is too complicated. Using the div  
> element is still a suitable way (div is remained in XHTML 2.0  
> without major changes, http://www.w3.org/TR/xhtml2/mod- 
> structural.html#edef_structural_div) I think.

It is not the same div. It is a completely different div in another  
namespace. That the local names are identical does not make them the  
same.

The Atom spec provides shortcuts for plain text, HTML and XHTML 1.x.  
That's it. Calling an incompatible language "XHTML" doesn't help. As  
far as Atom is concerned, XHTML 2.0 documents get the same treatment  
as any other XML document that doesn't use the XHTML 1.x namespace.

(Yes, I am aware of http://lists.w3.org/Archives/Public/www-html/ 
2006Nov/0025 , but that resolution doesn't really make XHTML 2.0 any  
more likely to be implemented.)

> For browsers' implementation, in fact, XHTML 1.1 is still not well- 
> supported. CSS 2 is another example of poor implementation by  
> browsers. I do think that Atom should not be easy to change or be  
> updated very frequently. That's why Atom should leave some extents  
> of forward compatibility.

If you start from XHTML 1.0 and go forward, you don't end up at XHTML  
2.0 but at XHTML5. Embedding XHTML5 in Atom will work out just fine.

Forward is here:
http://whatwg.org/specs/web-apps/current-work/

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

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Sun, 19 Nov 2006 23:14:36 +0800

Even though XHTML 2.0 cannot be carried under type="xhtml", I don't think that whole XHTML 2.0 document is required to be placed under type="application/xhtml+xml".

XHTML 2.0, on the other hand, is a member of the XHTML family according to the specification.

== Copied from http://www.w3.org/TR/xhtml2/introduction.html ==

*********************************

1.3. What are the XHTML 2 Modules?
XHTML 2 is a member of the XHTML Family of markup languages. It is an XHTML Host Language as defined in XHTML Modularization. As such, it is made up of a set of XHTML Modules that together describe the elements and attributes of the language, and their content model. XHTML 2 updates many of the modules defined in XHTML Modularization 1.0, and includes the updated versions of all those modules and their semantics. XHTML 2 also uses modules from Ruby, XML Events, and XForms.

The modules defined in this specification are largely extensions of the modules defined in XHTML Modularization 1.0. This specification also defines the semantics of the modules it includes. So, that means that unlike earlier versions of XHTML that relied upon the semantics defined in HTML 4, all of the semantics for XHTML 2 are defined either in this specification or in the specifications that it normatively references.

Even though the XHTML 2 modules are defined in this specification, they are available for use in other XHTML family markup languages. Over time, it is possible that the modules defined in this specification will migrate into the XHTML Modularization specification.

**********************************

Anyway, I know that HTML 5 is under development and provide good backward compatibility.

Franklin

-----Original Message-----
From: Henri Sivonen [mailto:[email-masked]] 
Sent: Sunday, November 19, 2006 22:49
To: Tse Shing Chi ((Franklin/Whale))
Cc: 'Atom Syntax'
Subject: Re: Forward Compatibility

Forward is here:

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

---

From: Antone Roundy <[email-masked]>
Date: Mon, 20 Nov 2006 08:19:04 -0600

On Nov 19, 2006, at 4:10 AM, Tse Shing Chi ((Franklin/Whale)) wrote:
> content or summary element, it is too complicated.

 From RFC 4287, section 4.1.3.3:

    4.  If the value of "type" is an XML media type [RFC3023] or 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 that would serve as
        the root element of the XML document of the indicated type.

I understand your not wanting to put a complete XHTML 2.0 document  
inside atom:content or atom:summary, but since DIV isn't supposed to  
be the root element of an XHTML 2.0 document, omitting the rest of  
the document violates at least the "spirit" of the Atom spec...though  
we didn't use normative language where it says "normally" to actually  
prohibit it.

We did however discuss and reject the idea of explicitly allowing  
document fragments of the specified MIME media type.  Doing so would  
have created ambiguity--you wouldn't know whether it was safe to hand  
the data off to a widget that only knows how to process complete  
documents, or whether it was a fragment that needed some sort of  
special treatment.

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 23:47:53 +0800

> we didn't use normative language where it says "normally" to actually  

But div is not the root element of XHTML 1.x as well.

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Nov 2006 07:53:33 -0800

IOW, using the XHTML2 div as the child is compliant in a strictly sense
but should be avoided because it will likely cause problems.

- James

Antone Roundy wrote:
> inside atom:content or atom:summary, but since DIV isn't supposed to be
> the root element of an XHTML 2.0 document, omitting the rest of the
> document violates at least the "spirit" of the Atom spec...though we
> didn't use normative language where it says "normally" to actually
> prohibit it.
> 
> documents, or whether it was a fragment that needed some sort of special
> treatment.
> 
>

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Nov 2006 08:12:31 -0800

Which is why type=xhtml" and type="application/xhtml+xml" need to be
treated differently.  With the former, the child is <div>, with the
latter it *should* be <html>.

- James

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 20 Nov 2006 23:28:03 +0200

> But div is not the root element of XHTML 1.x as well.

It isn't, but XHTML 1.x as type='xhtml' is a special case in Atom, so  
Atom processors need to know how to construct a full XHTML 1.x  
document from the Atom entry if they co-operate with an XHTML 1.x  
processing module that wants to see full documents.

Using an XHTML 1.x fragment with type='application/xhtml+xml' would  
not be proper.

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

---

From: Robert Sayre <[email-masked]>
Date: Wed, 22 Nov 2006 21:23:36 -0500

> but should be avoided because it will likely cause problems.

An XHTML2 div is not compliant. The normative reference is to XHTML 
Modularization, and the accompanying XHTML1 definitions and namespace. 
In practice, this requirement is somewhat malleable, since XHTML's DTD 
requires that all elements reside in the default namespace (a flaw in 
XHTML), and XHTML Modularization makes some other universally-ignored 
requirements.

XHTML2's namespace is different, though there is an open issue to change 
to the same namespace that XHTML1 uses. Even if the namespace were the 
same, Atom processors are not required expected to understand or comply 
with any XHTML[2] markup.

In other words, Atom processors will pick up (X)HTML features as they 
see fit. The spec is quite specific on this point (using the markup is a 
MAY). In practice, (X)HTML support and security varies widely.

-Rob

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Fri, 24 Nov 2006 13:43:26 +0800

> processing module that wants to see full documents.

It seems that... only extremely few of atom processors can do so at the moment... (Actually I am not sure if there is any)

Microsoft Office Outlook 2007, Mozilla Thunderbird 1.5.0.8 and Opera 9.1.8653 all fails to generate a full XHTML 1.x document.

Office shows a HTML document with <div xmlns="http://www.w3.org/1999/xhtml"><p xmlns="http://www.w3.org/1999/xhtml"><img ... /></p></div>.

Thunderbird is better... at least... does not have any xmlns=""... but XHTML's elements... such as <br />, <img ... />... still exists...

Opera has <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> in its generated source... with XHTML's elements like Thunderbird...

It seems that... even type="xhtml"... is lacking support from processors.

Franklin Tse

-----Original Message-----
From: Henri Sivonen [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 05:28
To: Tse Shing Chi ((Franklin/Whale))
Cc: [email-masked]
Subject: Re: Forward Compatibility

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