On Thu, Feb 10, 2005 at 01:20:55PM -0500, Sam Ruby wrote:
> 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.
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 PROTECTED] uncertaintydivision.org
