Subject: Re: some small comments on 08

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 25 May 2005 11:24:13 +0200 (CEST)

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 element@type="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)
           [@type='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

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 25 May 2005 12:32:02 +0100

>    content = getContent(element.children)

if xhtmlTypeContent(element ,'atom:content'):
   return stripContentFromDiv(element.child[0])

ie, when the @type=xhtml, pull back all the children underneath the 
xhtml:div child. Done. With less options come less conditionals. What's 
broken if broken is clearly determinable. There's no need to check for a 
discardable divs when the first child under content is assured to be.

> than linking Atom to XHTML or even more generally use "XML in XML".

What bothers me is inconsistent document production. Optionality of this 
feature invites that, ie making it optional defeats its purpose. There's 
no apparent benefit.

> other arguments. 

I don't buy the rationale for xhtml:div optionality and I've refuted it 
already. I'll sum up:

You said-

"I just want the XHTML div to be optional for people that don't need it 
but still meeting other people's needs of a "dummy container to carry 
their XHTML namespace declarations""

I said-

"If you can't trust people not to need the div, then you can't make it 
optional. I unfortunately have a good amount of experience dealing with 
this kind of thing outside Atompub. The simplest answer is to stop the 
'envelope' from using a default namespace (don't bother to debate this 
with me, it's not an imo). We're not doing that with Atom. Failing that, 
the next thing consideration is to add/enforce a protective scoping 
barrier between the envelope and the content. We are doing that with Atom."

You need to convince me why making this thing optional is beneficial. 
Thats not happening, what's happening is that you're telling me 
optionality, if we allow it, can be worked around, as long as everyone 
works around it the same way. One problem here is that you're assuming 
that the people who don't need this and the people who do this need 
won't cross each others paths. They will. If that is not a problem, then 
we can remove the construct altogether.

> I explained in [1] that a div (without attribute and without
> sibling) has no meaning and is never necessary. 

That's refutable - xhtml:div is a lexical scoping mechanism, it doesn't 
require meaning to be useful, and such a mechanism is clearly neccessary 
(according to the WG) in the presence of Atom created with default 
namespaces. What being proposed is not ime a robust solution and I would 
much rather we take our chances without such a mechanism that make it 
optional. Unless there are new arguments regarding the benefit of 
optionality, this is just restating positions and we remain deadlocked.

> If it is necessary in the

Don't do that. It's enlarging the state space; more conditionals to 
think about.

> their "taste" and having it become part of the content.

I have no idea what you meant there, but it sounded like something you 
haven't said before- can you clarify?

>[..]

The meaningless thing is starting to sound to me like a red herring. 
This construct, like any firewalling or defensive mechanism becomes 
useless the nanosecond it has served its purpose. That doesn't mean you 
just take it out or make the checks optional. I agree having to put that 
artefact in there is annoying, but unless you can persuade this WG and 
the XML community at large to do some root cause analysis so as to 
conclude that default namespaces are harmful, we're more or less stuck 
with this thing. Even if you can, I don't think it will be in time for 
us to ship. The best case scenario here is that we ship with 
non-optional xhtml:div and that down the line this creates further 
evidence in the communities that there is a root cause to look at.

> doesn't prevent it from discarding the div anyway.

Please look at all the qualifications that are been added to make this 
thing optional, those MAYS and SHOULDs. Add them up. Assess their 
overall impact. I have, as best I can, and I can't credibly conclude on 
the balance it's simpler or more robust than what we have. Sans 
interesting new arguments I'll hold my position.

cheers
Bill