* Antone Roundy <[EMAIL PROTECTED]> [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
