Thomas Broyer wrote:
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
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.
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".
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.
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.
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
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.
Don't do that. It's enlarging the state space; more conditionals to
think about.
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.
I have no idea what you meant there, but it sounded like something you
haven't said before- can you clarify?
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:
[..]
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).
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.
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.
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
