Bill de h�ra wrote:
> Thomas Broyer wrote:
>> * it is not less reliably implementable than the current draft's
>> mandatory div element; if we go for a SHOULD or MAY on discarding
>> the div elements, it is even *more* reliably implementable.
>
> We had a discussion about optional div not so long ago, and I came
> away unconvinced then. Can you present some arguments to back those
> opinions up?
As you're quoting the "reliable implementation" sentence, let's start
with some code and pseudo code to demonstrate PaceOptionalXhtmlDiv is
"reliably
implementable":
With a "pull" parser (.NET XmlReader, or DOM), using recursivity:
function getContent(nodelist) returns nodelist
if nodelist.length = 1 then
# a single element
var element = nodelist[0]
if element is xhtml:div and not(element has attributes) then
# the single element is a "discardable xhtml:div"
# apply the same function on its children (recursivity)
return getContent(element.children)
else
return nodelist
end if
else
return nodelist
end if
end function
...
The above function would be called like this:
if element is atom:content and [EMAIL PROTECTED]"xhtml" then
content = getContent(element.children)
end if
With a "rule-based" processor (XSLT), only accounting here for
atom:content: <!--
The following template applies a different processing whether it finds a
"discardable XHTML div" or not. When you find a "discardable XHTML div",
you have to "apply templates" to finds subsequent "discardable XHTML
div" inside that div. -->
<xsl:template name="process-xhtml-content">
<xsl:choose>
<xsl:when test="count(node()) = 1 and xhtml:div[not(@*)]">
<!-- discardable XHTML div, apply template -->
<xsl:apply-templates />
</xsl:when>
<xsl:otherwise>
<!-- here, we just copy the content -->
<xsl:copy-of select="node()" />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<!--
The following template matches any Text Construct or atom:content with
@type="xhtml". -->
<xsl:template
match="(atom:content|atom:title|atom:subtitle|atom:summary)
[EMAIL PROTECTED]'xhtml']">
<xsl:call-template name="process-xhtml-content" />
</xsl:template>
<!--
The following template matches any XHTML div with no attribute which is
the only child node of a Text Construct or an atom:content or xhtml:div
element. The XSLT transform author have to ensure this template never
matches a node in another context (e.g. if he applies templates to the
XHTML "real" content. -->
<xsl:template
match="(atom:content|atom:title|atom:subtitle|atom:summary|xhtml:div)
/xhtml:div[not(@*) and count(../node()) = 1]">
<xsl:call-template name="process-xhtml-content" />
</xsl:template>
============
Btw, from what I found in the archives for the last two months
(approximately), it seems that what bothers you is less the "optional div"
than linking Atom to XHTML or even more generally use "XML in XML".
You're asking for some more arguments, have you read "Re: Consensus call
on last raft of issues" [1]?
I'm open to discussion if you have a problem with something particular in
my proposal, but actually, without some hint, it'd be hard for me to find
other arguments. You were pointing the case where "a div is deemed
necessary", I explained in [1] that a div (without attribute and without
sibling) has no meaning and is never necessary. If it is necessary in the
application processing the Atom document, it's the responsibility of that
application to add it. If it is necessary in the application producing the
Atom document and this one has no mean to strip it, the Pace allows this
application to put that div in the Text Construct or atom:content, it just
says that such a div has no more meaning than the Atom element containing
it (that is, grouping its content altogether) and thus will be discarded
by the Atom Processor at the other end of the chain.
Note that I'm open to change the "MUST discard" into a SHOULD, as there is
no real need for this discarding.
Actually, that Pace wouldn't have been necessary if people wanting to
produce prefix-free feeds weren't bothered adding a "dummy" div to achieve
their "taste" and having it become part of the content.
The only reason for PaceOptionalXhtmlDiv beyond that, is for
interoperability in the Atom Publishing Protocol: the producer of the Atom
document (the client when doing a POST or PUT, the server when doing a
GET) is free to add as many "dummy" divs like that without the consumer
considering them part of the content. Thus, the following would be OK:
Client:
PUT ... HTTP/1.1
...
<entry xmlns="...Atom NS...">
...
<content type="xhtml">
<!-- I'm using a dummy div because I want prefix-free documents. -->
<div xmlns="http://www.w3.org/1999/xhtml";>
Blabla
</div>
</content>
...
</entry>
Server:
HTTP/1.1 200 OK
...
<atom:entry xmlns:atom="...Atom NS..." xmlns="http://www.w3.org/1999/xhtml";>
...
<atom:content type="xhtml">
Blabla
</atom:content>
...
</atom:entry>
In the same way we prevent type="text" to use preformatted text and we
enforce type="xhtml" to contain XHTML that could validly appear in a div
element, we can say XHTML "real" content cannot consist of a single div
with no attribute. We don't forbid Text Construct's and atom:content's
content to be such a thing, we just say it is not part of the content
(because we have technical arguments, explained in [1], to assure such a
div is meaningless and useless and can thus safely be discarded).
Moreover, we're saying that Atom Processors MAY use the markup, this means
they may also not use it or use only part of it (e.g. discard/ignore some
elements or attributes such as script, style, object, applet, etc.), which
doesn't prevent it from discarding the div anyway.
[1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html
--
Thomas Broyer
