Re: On PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 17, 2005, at 15:09, Bill de hÓra wrote:
1. About Rob's example from MT; the point is twofold a) that what the 
tool provides ootb
Wasn't that what type='HTML' was for?
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: On PaceXhtmlNamespaceDiv

[Bill de hÓra]

Martin Duerst wrote:
At 20:44 05/02/17, Bill de hãra wrote:
 >
 >Martin Duerst wrote:
 >> At 19:03 05/02/16, Bill de hçãra wrote:
 >>  >The point I'm seeing here is that creating markup using string 
concats is inherently fragile. No surpise there. Wrt namespaces, 
fragility is eliminated when you stop using  defaults (but there are 
other considerations which keep string concat fragile). Use of div 
covers off the XHTML case.
 >> Yes, use of div covers that case. But that doesn't mean that if
 >> some people want to use div, everybody has to use div.
 >
 >It does (I've never said otherwise) - there is a div tax.

I'm okay with those paying div tax who think they need a div.
I'm not okay with everybody paying div tax for no apparent
general benefit.

I should qualify this tax idea.
1. About Rob's example from MT; the point is twofold a) that what the 
tool provides ootb, b) we can't expect everyone understand the issue as 
well as Rob or we do. Asking questions about how he has his blog setup 
is missing the point. The point is how we expect Atom to help the other 
5 million users generate sound feeds.

2. As things stand there's tradeoff here between robustness and markup 
generation.

4. The general benefit implied by the pace is a reduced amount of 
garbage content.

3. As I've said before the answer to this issue is to stop Atom going 
out in a default namespace as they are actively harmful. That is the 
most cost-effective and general useful solution.

cheers
Bill

Re: On PaceXhtmlNamespaceDiv

[Martin Duerst]

(BAt 20:44 05/02/17, Bill de h$B".(Bra wrote:
(B >
(B >Martin Duerst wrote:
(B >> At 19:03 05/02/16, Bill de h$Bec!V(Bra wrote:
(B
(B >>  >The point I'm seeing here is that creating markup using string 
(Bconcats is inherently fragile. No surpise there. Wrt namespaces, fragility 
(Bis eliminated when you stop using  defaults (but there are other 
(Bconsiderations which keep string concat fragile). Use of div covers off the 
(BXHTML case.
(B >> Yes, use of div covers that case. But that doesn't mean that if
(B >> some people want to use div, everybody has to use div.
(B >
(B >It does (I've never said otherwise) - there is a div tax.
(B
(BI'm okay with those paying div tax who think they need a div.
(BI'm not okay with everybody paying div tax for no apparent
(Bgeneral benefit.
(B
(BRegards,Martin. 

More thouhts on PaceXhtmlNamespaceDiv

[Anne van Kesteren]

There is only a single way in which a required DIV element in
|type="XHTML"| would be useful. It would only be useful if the XHTML
namespace was defined directly on the DIV element, like:
 
  http://www.w3.org/1999/xhtml";>
   ...
  
 
The DIV element would obviously not be considered part of the content
and all the elements inside the DIV element should inherit the XHTML
namespace and should not have a namespace prefix.
Than it would be possible to easy copy and paste and easily generate it
from string-generators, like MovableType and WordPress.
However, this would seriously limit |type="XHTML"| and would require the
Atom specification to define the DTD for the allowed XHTML elements.
Since you can use MathML and SVG in a valid way inside the DIV element
as well, with the proper DTD. For some people that is quite normal[1].
IMHO it would be better if your system can not guarentee to generate
well-formed XHTML it would use |type="HTML"|. That is also interoperable
and can be easily copy and pasted. I think we should recommend that to
publishers instead of limiting |type="XHTML"|.
However, if we do want to limit |type="XHTML"| in this way we should do
in a way that makes it useful. By defining the DTD and the exact way the
namespace declarations should happen.
[1]
--
 Anne van Kesteren
 

Re: On PaceXhtmlNamespaceDiv

[Bill de hÓra]

Martin Duerst wrote:
At 19:03 05/02/16, Bill de hãra wrote:
 >> As long as it's XML and otherwise conformant, I think it's fine.
 >>  >Probably not. Do you and Julian and Anne and Henri approve?
 >> I don't see how I would want to complain about how you generate
 >> your stuff, as long as the result is following the specs.
 >
 >The point I'm seeing here is that creating markup using string concats 
is inherently fragile. No surpise there. Wrt namespaces, fragility is 
eliminated when you stop using  defaults (but there are other 
considerations which keep string concat fragile). Use of div covers off 
the XHTML case.

Yes, use of div covers that case. But that doesn't mean that if
some people want to use div, everybody has to use div.
It does (I've never said otherwise) - there is a div tax.
cheers
Bill

Re: On PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 17, 2005, at 00:18, Robert Sayre wrote:
 >However, this is not going to reflect what's in MySQL.
Does it need to? Could anybody except for you check?
Should anybody (including you) care? Is it part of conformance?
Yes. No. Yes. Yes.
Why does the feed have to reflect what is in MySQL? What if you had 
Markdown content (or similar non-(X)HTML) in MySQL?

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: PaceXhtmlNamespaceDiv

[Martin Duerst]

(BAt 01:35 05/02/11, Sam Ruby wrote:
(B >
(B >Julian Reschke wrote:
(B
(B >> Nor am I. The question is what's the best way to enhance the spec. One 
(Balternative suggestion was made by Martin D$B—S(Bst in 
(B:
(B >> "Note: It is important to make sure that correct namespace declarations
(B >> for XHTML are present. One way to do this is by using an 
(B >> element as the content of the  element and specifying
(B >> the XHTML namespace on that div element. Here are some examples:
(B >> ... [use proposed examples]
(B >> There are other ways to declare the namespace URI for XHTML content;
(B >> this specification does not limit the placement of such declarations
(B >> in any way."
(B >
(B >My issue with that wording is that it doesn't make it clear whether the 
(Bxhtml:div that is added is to be considered a part of the content or not.
(B
(BFair point.
(B
(B >Put another way, how does the consumer know that if a given xhtml:div 
(Belement is part of the content, or was added per the above?
(B >
(B >Julian, you previously said "Let's make the spec as clear and simple as 
(Bpossible."  How about this:
(B >
(B >   xhtml:div is required.  xhtml:div is not part of the content.
(B >
(B >Clear.  Simple.  And difficult to get wrong.
(B
(BHow about the following alternative:
(B
(B xhtml:div is not required. xhtml:div is part of the content.
(B
(BClear. Simple. And difficult to get wrong :-).
(B
(BIf that's not enough, we can add a note, e.g.:
(B
(B Note: A xhtml:div is just an empty wrapper; it will in general
(B   not affect the processing or display of the content.
(B
(B
(BRegards,Martin. 

Re: On PaceXhtmlNamespaceDiv

[Martin Duerst]

(BAt 19:03 05/02/16, Bill de h$B%b(Bra wrote:
(B
(B >> As long as it's XML and otherwise conformant, I think it's fine.
(B >>  >Probably not. Do you and Julian and Anne and Henri approve?
(B >> I don't see how I would want to complain about how you generate
(B >> your stuff, as long as the result is following the specs.
(B >
(B >The point I'm seeing here is that creating markup using string concats is 
(Binherently fragile. No surpise there. Wrt namespaces, fragility is 
(Beliminated when you stop using  defaults (but there are other 
(Bconsiderations which keep string concat fragile). Use of div covers off the 
(BXHTML case.
(B
(BYes, use of div covers that case. But that doesn't mean that if
(Bsome people want to use div, everybody has to use div.
(B
(BRegards,Martin. 

Re: On PaceXhtmlNamespaceDiv

[Robert Sayre]

Henri Sivonen wrote:
How's that relevant wrt. type='XHTML'? If you doubt the robustness of 
concatenation with XHTML, why wouldn't you keep using "entity-encoded 
HTML"?

Anne Van Kesteren wrote:
And, now I look at it, Robert is using HTML (the text/html MIME type 
implies that) so I do not see the problem.



Anne, Henri: thank you for missing the point.
Martin Duerst wrote:

 >However, this is not going to reflect what's in MySQL.
Does it need to? Could anybody except for you check?
Should anybody (including you) care? Is it part of conformance?
Yes. No. Yes. Yes.
Robert Sayre

Re: On PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 16, 2005, at 10:53, Robert Sayre wrote:
This is how I generate my Atom 0.3 feed, using the popular Movable 
Type program:

">
  <$MTEntryBody encode_xml="1"$>

How's that relevant wrt. type='XHTML'? If you doubt the robustness of 
concatenation with XHTML, why wouldn't you keep using "entity-encoded 
HTML"?

(FWIW, I don't believe the pace removes the telescoping divs issue. I 
predict the div as part of the envelope is unintuitive to the 
ViewSourceClan, who will assume everything in the Atom namespace is 
part of the envelope and everything in the XHTML namespace is part of 
the payload.)

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: On PaceXhtmlNamespaceDiv

[Anne van Kesteren]

Bill de hÃra wrote:
As long as it's XML and otherwise conformant, I think it's fine.
Do you and Julian and Anne and Henri approve?
I don't see how I would want to complain about how you generate
your stuff, as long as the result is following the specs.
The point I'm seeing here is that creating markup using string concats 
is inherently fragile. No surpise there. Wrt namespaces, fragility is 
eliminated when you stop using  defaults (but there are other 
considerations which keep string concat fragile). Use of div covers off 
the XHTML case.
IMHO you are better of using HTML in such cases. Since you can not 
guarentee that your input and therefore your output will always be 
well-formed XML.

And, now I look at it, Robert is using HTML (the text/html MIME type 
implies that) so I do not see the problem.

--
 Anne van Kesteren
 

Re: On PaceXhtmlNamespaceDiv

[Bill de hÓra]

Martin Duerst wrote:
 >This is how I generate my Atom 0.3 feed, using the popular Movable 
Type program:
 >
 >
 >  mode="escaped"
 >  xml:lang="en"
 >  xml:base="<$MTBlogURL encode_xml="1"$>">
 >   <$MTEntryBody encode_xml="1"$>
 >

Not a single namespace declaration here, so it's rather
unclear to me what's going on (except if this is an
explicitly wrong example, in which case I don't understand
why it is here, because we know people get things wrong
without needing examples.
Martin,
Rob probably has a feed root element as follows
http://purl.org/atom/ns#";
   xmlns:dc="http://purl.org/dc/elements/1.1/";
   xml:lang="en">
ie the feed is served using a default ns (I'm not sure whether you can 
alter this in MT without altering MT).


As long as it's XML and otherwise conformant, I think it's fine.
 >Probably not. Do you and Julian and Anne and Henri approve?
I don't see how I would want to complain about how you generate
your stuff, as long as the result is following the specs.
The point I'm seeing here is that creating markup using string concats 
is inherently fragile. No surpise there. Wrt namespaces, fragility is 
eliminated when you stop using  defaults (but there are other 
considerations which keep string concat fragile). Use of div covers off 
the XHTML case.

cheers
Bill

Re: On PaceXhtmlNamespaceDiv

[Martin Duerst]

Hello Robert,
I'm not sure I understand your point(s) from your mail below.
At 17:53 05/02/16, Robert Sayre wrote:
>This is how I generate my Atom 0.3 feed, using the popular Movable Type 
program:
>
>  mode="escaped"
>  xml:lang="en"
>  xml:base="<$MTBlogURL encode_xml="1"$>">
>   <$MTEntryBody encode_xml="1"$>
>
Not a single namespace declaration here, so it's rather
unclear to me what's going on (except if this is an
explicitly wrong example, in which case I don't understand
why it is here, because we know people get things wrong
without needing examples.
>I enter the "EntryBody" in an HTML form, by hand. Then, a Perl script 
runs through the template I excerpted above, and generates the feed. The 
template approach is neat, because it lets only slighty technical users 
modify their content with a lot of flexibility and power.

No problem with that in principle.
>Is this a smart way to generate XML from a purely technical perspective?
As long as it's XML and otherwise conformant, I think it's fine.
>Probably not. Do you and Julian and Anne and Henri approve?
I don't see how I would want to complain about how you generate
your stuff, as long as the result is following the specs.
>Probably not. Will tools stop generating feeds this way in the forseeable 
future? Probably not.
>
>My homepage is valid XHTML[0], as are lots of folks'. They are going to 
take their PHP, Perl, Python, JavaScript, and Visual Basic, and use the 
basic string functions of those languages to cobble together a feed. They 
are probably going to go with "XHTML" for ease. They are not going to get 
the namespace right at first, so they are going to add a div element around 
the outside.

All fine. I don't have any problem if they get here. If they add a 
to get the namespaces stuff right, great. If they figure out that
they can use an explicit atom: prefix in the template, and declare
the html namespace as default, also great. There are many ways to
get namespaces right, even in a simple template/concatenation
implementation.
>However, this is not going to reflect what's in MySQL.
Does it need to? Could anybody except for you check?
Should anybody (including you) care? Is it part of conformance?
Regards, Martin.
>Robert Sayre
>
>[0] http://validator.w3.org/check?uri=http%3A%2F%2Ffranklinmint.fm
> 

Re: On PaceXhtmlNamespaceDiv

[Robert Sayre]

Martin Duerst wrote:
[I appologize that this comes late. I was ill last week.]
I'm also still not convinced about this one. It was introduced
with a very good motivation, namely that it would increase the
chance that namespaces would be used correctly. After the changes,
what I understand is left is the following:
Everybody has to use an XHTML  in every atom  of
type "XHTML", just to make sure that Sam (any others?) can
realize his dream of "atom without namespace prefixes".
This is how I generate my Atom 0.3 feed, using the popular Movable Type 
program:

">
  <$MTEntryBody encode_xml="1"$>

I enter the "EntryBody" in an HTML form, by hand. Then, a Perl script 
runs through the template I excerpted above, and generates the feed. The 
template approach is neat, because it lets only slighty technical users 
modify their content with a lot of flexibility and power.

Is this a smart way to generate XML from a purely technical perspective? 
Probably not. Do you and Julian and Anne and Henri approve? Probably 
not. Will tools stop generating feeds this way in the forseeable future? 
Probably not.

My homepage is valid XHTML[0], as are lots of folks'. They are going to 
take their PHP, Perl, Python, JavaScript, and Visual Basic, and use the 
basic string functions of those languages to cobble together a feed. 
They are probably going to go with "XHTML" for ease. They are not going 
to get the namespace right at first, so they are going to add a div 
element around the outside. However, this is not going to reflect what's 
in MySQL.

Robert Sayre
[0] http://validator.w3.org/check?uri=http%3A%2F%2Ffranklinmint.fm

Re: On PaceXhtmlNamespaceDiv

[Julian Reschke]

Martin Duerst wrote:
...
For the record: I agree with Martin's analysis.
Best regards, Julian

Re: On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round ofPaces)

[Martin Duerst]

[I appologize that this comes late. I was ill last week.]
I'm also still not convinced about this one. It was introduced
with a very good motivation, namely that it would increase the
chance that namespaces would be used correctly. After the changes,
what I understand is left is the following:
Everybody has to use an XHTML  in every atom  of
type "XHTML", just to make sure that Sam (any others?) can
realize his dream of "atom without namespace prefixes".
This despite the fact that those that want to avoid any and
all namespace prefixes can use a  on their own if they
want. As Sam explained, the  in that case would be part
of the content. That's true, but while adding a  formally
changes the content, it doesn't actually change the content,
because  is just a dummy wrapper, in particular if there
are no other attributes than the default namespace
declaration.
On more general terms, I have observed different choices of
how different namespaces get put together over the last
three if not more years. For the simple case of "namespace
B in namespace A", a variety of choices, with a variety of
reasons, has been proposed.
On the outer side (namespace A), the choices range from
"foreign namespace stuff can be inserted pretty much anywhere
where it makes sense, just put it in" to "we have a ''
element, anything from another namespace has to go in there".
On the inner side (namespace B), the choices again range
from "any B element can be used" to "only a wrapper element
can be used".
As an example, SVG tends to high explicity on both sides,
for the inner side, see "included document fragments"
(http://www.w3.org/TR/SVG11/conform#ConformingSVGIncludedDocuments),
for the outer side, see 
(http://www.w3.org/TR/SVG11/extend#ForeignObjectElement).
Most of the motivation for this explicitness in SVG comes from
the fact that without being clear on coordinates/placement/size,
things won't work.
Looking at these cases, it seems to me that what we are doing
with  is really thinly motivated (no need for any special
information such as coordinates), and is also in a way abusing
, which was created to indicate divisions in HTML documents,
not to serve as a throw-away default namespace holder in foreign
document formats. Actually, instead of , we could as well
define that we use , or we could even define that we use
something new like . Because as it turns out, while this
element is in the XHTML namespace, it's never part of an XHTML
fragment that an XHTML processor would see.
At 05:05 05/02/16, Anne van Kesteren wrote:
>
>Tim Bray wrote:
>> PaceXhtmlNamespaceDiv
>> This is tough.  There are some people who are really against this and 
who aren't moving.  On the other hand, there are way more who are in favor. 
Reviewing the discussion, the contras are saying that this is sloppy and 
unnecessary and if it solves a problem, that problem really shouldn't be 
there, but they don't seem to be saying it's actively harmful.  But the 
people in favor are arguing that this will reduce errors and improve 
interop.  Also, the Pace was changed in midstream.
>> Also, Paul thinks we will get feedback on this from out there in the IETF.

I'm not sure I understand this sentence. Does Paul think that we will
get feedback in the IETF to put it in anyway, so we better already
put it in? Or that we'll get feedback to take that out in the IETF
so we can as well leave it in for the moment? Or what?
Regards,Martin.
>> DISPOSITION: Borderline, but accepted.
>
>I'm still not sure how it would improve interop, especially since the 
place the namespace can be defined is optional. I do not think those 
"Planet aggregators" would handle the following correct for example:
>
>  http://www.w3.org/1999/xhtml";>
>   
>
> Foo 
> Et cetera.
>...
>
>Also, this restriction can be avoided by using |type="application/xml"| 
or |type="application/xhtml+xml"| I assume? (Although that is probably not 
valid for the TITLE or SUMMARY element (it should be).)
>
>
>--
>  Anne van Kesteren
>  <http://annevankesteren.nl/>
> 

On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round of Paces)

[Anne van Kesteren]

Tim Bray wrote:
PaceXhtmlNamespaceDiv
This is tough.  There are some people who are really against this and 
who aren't moving.  On the other hand, there are way more who are in 
favor.  Reviewing the discussion, the contras are saying that this is 
sloppy and unnecessary and if it solves a problem, that problem really 
shouldn't be there, but they don't seem to be saying it's actively 
harmful.  But the people in favor are arguing that this will reduce 
errors and improve interop.  Also, the Pace was changed in midstream.  
Also, Paul thinks we will get feedback on this from out there in the IETF.
DISPOSITION: Borderline, but accepted.
I'm still not sure how it would improve interop, especially since the 
place the namespace can be defined is optional. I do not think those 
"Planet aggregators" would handle the following correct for example:

 http://www.w3.org/1999/xhtml";>
  
   
Foo 
Et cetera.
   ...
Also, this restriction can be avoided by using |type="application/xml"| 
or |type="application/xhtml+xml"| I assume? (Although that is probably 
not valid for the TITLE or SUMMARY element (it should be).)

--
 Anne van Kesteren
 <http://annevankesteren.nl/>

Re: PaceXhtmlNamespaceDiv

[James Aylett]

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  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

Re: PaceXhtmlNamespaceDiv

[Roger B.]

> >   
> 
> That seems like a
> good approach for those who do want the default namespace here.

Julian: It might actually be the best compromise solution. Advanced
developers will understand what's happening, and View-Sourcers can
copy-n-paste that just as easily as they can copy-n-paste
.

The people left out in this scenario are intermediate developers...
folks who know just enough to find such a construct confusing.  I
suspect Sam would prefer it if all three groups could get something
they can grok, but if that proves impossible, the intermediate folks
may be the ones we can politically afford to fluster.

For what it's worth, I'm still +1 on requiring the . 'Cause
personally, I figure if we're going to inconvenience anyone, it should
be the most advanced among us.

--
Roger Benningfield
JournURL

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:
Julian Reschke wrote:
Sam, thanks for the long reply. I'll try my best to dig it and to offer 
constructive remarks...

To summarize my p.o.v.:
- the spec shouldn't require any specific container element for XHTML 
content,

We continue to talk past one another.  The above line is key.
Some examples might help.  Perhaps once we are actually understanding 
each other's points, then we can work backward from there to spec text.

So, suppose my XHTML content is:
  What a nice day!
My XHTML container element is .  That is completely my choice.  It is 
not required by the spec.
Yep.
Now if I place that inside an atom feed, I'm going to get something like 
this (heavily elided, all namespace details omitted):

  

  
 What a nice day!
  

  
Yep.
Depending on the how the question is phrased, one could take the 
position that , , and  are container elements.  Or 
not.  Again, depending on how the question is phrased.
Fine with me.
I don't believe that these elements are the ones that you have an issue 
with.  Correct?
Yes.
Now, consider a different document, again heavily elided, etc:
  

  
 
   What a nice day!
 
  

  
The key difference between these two documents is that instead of three 
elements around which there should be no issue, there now are four.  But 
for some reason, this causes a big controversy.

My theory is that the controversy is that people initially assumed that 
this div element was to be considered part of the content and not part 
of the format.  And thereby was mandating that all content have a given 
container element.  An entirely unreasonable mandate.
Well, the current spec says it's part of the content. I personally feel 
it really doesn't matter. Adding DIVs around XHTML content doesn't 
change the semantics of the content, in particular if it doesn't carry 
any additional attributes.

So, I wouldn't have any problems with recipients that collapse multiple 
nested xhtml:div elements into one or none (in absence of other 
attributes on it).

I agree that this would be an unreasonable mandate.  But I don't want to 
force a top level container element for the xhtml, I want to define a 
bottom level container element in the format for the xhtml.  There is a 
big difference.
It's still hard to see the difference, It's certainy not obvious on the 
syntactical level, and at the end of the day, that's what we are 
discussing here, right?

The difference between four feed container elements and mandating that 
all xhtml content have a uniform top level container element.  Which 
again, I will agree is an entirely unreasonable assumption.

 - - -
On the optimistic presumption that you are with me so far, I'll press 
on.  What desirable characteristics are there for feed container 
Not entirely, but trying :-)
elements in this circumstance?
To answer that question, it is important to understand how CMS software 
tends to be implemented.  In particular, how they are layered.  This is 
difficult as there isn't any one reference implementation that we can 
consult.  We also need to consider software which isn't written yet.  As 
I said, this is diffuclt.

But we can observe common problems that people have had, and try to 
engineer a solution that avoids them.  I hold the belief that if 
somebody writes a simple and clear spec that a significant number of 
people get wrong, that we are looking at a spec bug.
Sure. But, are we looking at the whole set of implementors, or only 
those who actually read the spec? We all know that those sets aren't 
identical...

Enough hand waving, onto the problem at hand.  What we are looking at 
here is an xhtml fragment.  Not a complete xhtml document, but some 
fragment of a web page.
Yes.
Now, fragments tend not to exist independent of a context.  And in 
virtually all xhtml documents I have seen (including the ones I 
produce), any fragment presumes that the xhtml namespace was defined as 
the default namespace earlier in the document (in particular, on the 
document element).
Well, that depends how you define "fragment". For instance, I can use 
XSLT to produce that fragment and I certainly don't have to make any 
assumptions about default namespaces. The XSLT processor cares for me. 
The same thing applies when serializing a node set from an 
namespace-aware DOM (at least that's what I'd expect and MSXML has been 
doing for years now).

So, a desirable characteristic for a container element would be one in 
which the default namespace can be set.
I disagree that this is important, but the atom text constructs do have 
that characteristic already.

At this point, the discussion can fragment into any number of different 
directions.

  - - -
One is for those who view XML as merely one potential serialization 
format, and something that their tool takes care of for them.  For them, 
double escaping the content is the right answer, the simplest thing that 
can possibly work, end of 

Re: PaceXhtmlNamespaceDiv

[Bill de hÓra]

Sam Ruby wrote:
> [..snip excellent rationale..]
So, a desirable characteristic for a container element would be one in 
which the default namespace can be set.
That is not a desirable characteristic.

At this point, the discussion can fragment into any number of different 
directions.

[...]

Another is to declare the use of default namespaces as evil, and rewrite 
 both the document and the content to use explicit namespaces on every 
element.  This may very well be where you and I part ways.  If so, 
peace.  Just please give the people who want to use default namespaces 
the same consideration that I am willing to give those who wish to 
double escape.
I believe the easiest, most robust, least error-prone approach to this 
sort of problem is to attempt to eliminate default namespace usage 
whenever possible. Every time a default namespace is elided system 
robustness and comprehension are improved - I've never seen it work the 
other way.


And finally, there is a desire to create a format that can be done 
entirely with default namespaces, and without the need to rewrite or 
modify the content.
That is a questionable desire. It leads us directly to promoting the use 
of a div wrapper to protect XHTML from Atom. Any container format that 
can so easily damage content we have to enforce a shim to protect it, 
arguably has a design flaw. Atom is just the most of recent of string of 
flawed container formats.


So, what would a desirable feed container element be for this scenario? 
 I would suggest that it would be something in the xhtml namespace.  If 
it were in the atom namespace, you would have to do something along the 
lines of:

  
Sam is 100% right this is problem. I arrive at a very different conclusion.

If you are still with me, what I am proposing is that the simplest and 
cleanest solution for people who like default namespaces would be to 
define the format so that there is an  element between the 
 and the xhtml fragment that is being syndicated.
It's interesting you call them out so specifically, but no - default 
namespaces are the problem. Free your mind, and all that.

This can be solved in a general way, not just for XHTML, by banning the 
use of default namespaces for Atom elements. That means the Atom format 
would actively subset XMLNS. I see that as a preferable option to 
anything presented in this thread.

[Although it's time past for paces, I have one on this computer 
somewhere for default namespaces, but after I got shouted down last year 
about xmlns="" I didn't think there was much point. Maybe I'll publish 
it on April 1st]

In the meantime I support Sam's position, but think we're missing an 
opportunity to produce a more robust XML container format.

cheers
Bill

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
To summarize my p.o.v.:
- the spec shouldn't require any specific container element for XHTML 
content,
We continue to talk past one another.  The above line is key.
Some examples might help.  Perhaps once we are actually understanding 
each other's points, then we can work backward from there to spec text.

So, suppose my XHTML content is:
  What a nice day!
My XHTML container element is .  That is completely my choice.  It is 
not required by the spec.

Now if I place that inside an atom feed, I'm going to get something like 
this (heavily elided, all namespace details omitted):

  

  
 What a nice day!
  

  
Depending on the how the question is phrased, one could take the 
position that , , and  are container elements.  Or 
not.  Again, depending on how the question is phrased.

I don't believe that these elements are the ones that you have an issue 
with.  Correct?

Now, consider a different document, again heavily elided, etc:
  

  
 
   What a nice day!
 
  

  
The key difference between these two documents is that instead of three 
elements around which there should be no issue, there now are four.  But 
for some reason, this causes a big controversy.

My theory is that the controversy is that people initially assumed that 
this div element was to be considered part of the content and not part 
of the format.  And thereby was mandating that all content have a given 
container element.  An entirely unreasonable mandate.

I agree that this would be an unreasonable mandate.  But I don't want to 
force a top level container element for the xhtml, I want to define a 
bottom level container element in the format for the xhtml.  There is a 
big difference.

The difference between four feed container elements and mandating that 
all xhtml content have a uniform top level container element.  Which 
again, I will agree is an entirely unreasonable assumption.

 - - -
On the optimistic presumption that you are with me so far, I'll press 
on.  What desirable characteristics are there for feed container 
elements in this circumstance?

To answer that question, it is important to understand how CMS software 
tends to be implemented.  In particular, how they are layered.  This is 
difficult as there isn't any one reference implementation that we can 
consult.  We also need to consider software which isn't written yet.  As 
I said, this is diffuclt.

But we can observe common problems that people have had, and try to 
engineer a solution that avoids them.  I hold the belief that if 
somebody writes a simple and clear spec that a significant number of 
people get wrong, that we are looking at a spec bug.

Enough hand waving, onto the problem at hand.  What we are looking at 
here is an xhtml fragment.  Not a complete xhtml document, but some 
fragment of a web page.

Now, fragments tend not to exist independent of a context.  And in 
virtually all xhtml documents I have seen (including the ones I 
produce), any fragment presumes that the xhtml namespace was defined as 
the default namespace earlier in the document (in particular, on the 
document element).

So, a desirable characteristic for a container element would be one in 
which the default namespace can be set.

At this point, the discussion can fragment into any number of different 
directions.

  - - -
One is for those who view XML as merely one potential serialization 
format, and something that their tool takes care of for them.  For them, 
double escaping the content is the right answer, the simplest thing that 
can possibly work, end of discussion.  While neither you nor I are in 
that camp (nor is Norm, and others), I am quite willing to leave that as 
a valid option, as long as it is explicitly declared.

Another is to declare the use of default namespaces as evil, and rewrite 
 both the document and the content to use explicit namespaces on every 
element.  This may very well be where you and I part ways.  If so, 
peace.  Just please give the people who want to use default namespaces 
the same consideration that I am willing to give those who wish to 
double escape.

And finally, there is a desire to create a format that can be done 
entirely with default namespaces, and without the need to rewrite or 
modify the content.

The simple fact is that well formed xhtml does not always exist in the 
form of DOM nodes.  Sometimes it is serialized as a string and stored in 
a file or a MySQL database.  That does not make it any less well formed. 
 It doesn't mean that it wasn't produced by a proper tool.

Not having seen Tim's implementation, I'm just speculating at this 
point, but it probably falls into this category.  Based on the tools he 
is using, he is confident that his content is well formed, even if it is 
stored as a string.  As such, he can confidently use simple string 
concatenation as long as he can be assured that the default namespace is 
correct.

Whethe

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Robert Sayre wrote:
Julian Reschke wrote:
So do you think we'll have to live with that, or should the spec be 
clarified/changed to reduce the chance of people getting it wrong?

I think Sam's approach is best. The objections are all impractical 
pedantry.
I think the proposal won't really help for cases where people don't know 
what they do and/or use the wrong tools, but adds completely unnecessary 
complexity for everybody else.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Robert Sayre]

Julian Reschke wrote:
So do you think we'll have to live with that, or should the spec be 
clarified/changed to reduce the chance of people getting it wrong?
I think Sam's approach is best. The objections are all impractical pedantry.
Robert Sayre

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Robert Sayre wrote:
Henri Sivonen wrote:
Despite the "tools will save us" argument being unpopular, I think it 
is unwise for an average developer to approach XMLNS without proper 
tools.

Doesn't really matter what your preference is. People *will* generate 
Atom content without "proper tools". They will not learn their lesson 
from a bunch of strict clients. Rather, there will be "street Atom", 
where Atom's namespace will have a bunch of elements with same local 
name as XHTML elements.
So do you think we'll have to live with that, or should the spec be 
clarified/changed to reduce the chance of people getting it wrong?

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Robert Sayre]

Henri Sivonen wrote:
Despite the "tools will save 
us" argument being unpopular, I think it is unwise for an average 
developer to approach XMLNS without proper tools.

Doesn't really matter what your preference is. People *will* generate 
Atom content without "proper tools". They will not learn their lesson 
from a bunch of strict clients. Rather, there will be "street Atom", 
where Atom's namespace will have a bunch of elements with same local 
name as XHTML elements.

Robert Sayre

Re: PaceXhtmlNamespaceDiv

[Graham]

On 10 Feb 2005, at 3:35 pm, Sam Ruby wrote:
  The xhtml:div element itself MUST NOT be considered part of the
  content.
What does this mean? Define "content" and "considered" please.
Graham

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Sam Ruby wrote:
>   xhtml:div is required.  xhtml:div is not part of the content.
>
> Clear.  Simple.  And difficult to get wrong.
I'd much prefer:
  xhtml:div is required. xhtml:div is part of the content.
But I can live with it either way
- James M Snell

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:

Nor am I. The question is what's the best way to enhance the spec. One
alternative suggestion was made by Martin Dürst in 
:

"Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an 
element as the content of the  element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way."

My issue with that wording is that it doesn't make it clear whether the 
xhtml:div that is added is to be considered a part of the content or not.
I'd assume it's part of the content because that's what the spec 
currently says.

Put another way, how does the consumer know that if a given xhtml:div 
element is part of the content, or was added per the above?
It is, unless the spec says otherwise.
Julian, you previously said "Let's make the spec as clear and simple as 
possible."  How about this:

  xhtml:div is required.  xhtml:div is not part of the content.
Clear.  Simple.  And difficult to get wrong.
Well, but not sufficient as spec text right?
To summarize my p.o.v.:
- the spec shouldn't require any specific container element for XHTML 
content,

- the spec should warn people about that the child elements MUST be in 
the XHTML namespace if the recipient is supposed to interpret them as as 
XHTML markup,

- whether or not a feed producer puts in a  container doesn't seem 
to be relevant to me as it doesn't affect the semantics of what the text 
construct carries.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
Sam Ruby wrote:
That is consistent with your prior statement that you don't believe 
that implementation issues should affect the format:

http://www.imc.org/atom-syntax/mail-archive/msg12699.html
What I said is that very *specific* implementation issue shouldn't 
affect the format. Please cite correctly. I also posted the following 
clarification in 
:

"OK, I'll try to rephrase: changing the protocol format because one 
implementor says that this makes it easier to implement IMHO is a bad 
idea. Of course things look differently if this issue affects more 
platforms/parsers/toolkits.

So yes, more information is needed."
Yes, I want a spec that is simple.  I also want a spec that average 
people can implement simply and correctly.

We have seen on this very mailing list people who have an above 
average understanding of XML trip over this particular area numerous 
times.

I am not content to create a format for which the answers to such 
common user errors is "so be it".
Nor am I. The question is what's the best way to enhance the spec. One 
alternative suggestion was made by Martin Dürst in 
:

"Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an 
element as the content of the  element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way."
My issue with that wording is that it doesn't make it clear whether the 
xhtml:div that is added is to be considered a part of the content or not.

Put another way, how does the consumer know that if a given xhtml:div 
element is part of the content, or was added per the above?

Julian, you previously said "Let's make the spec as clear and simple as 
possible."  How about this:

  xhtml:div is required.  xhtml:div is not part of the content.
Clear.  Simple.  And difficult to get wrong.
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 10, 2005, at 18:02, Sam Ruby wrote:
We have seen on this very mailing list people who have an above 
average understanding of XML trip over this particular area numerous 
times.
Those trip-ups have not been as much about div vs. no div but about 
XMLNS which we can't and should not attempt to change. I should also 
note that typed examples on the list and output from debugged 
serializers are different things.*

* Aka. the "tools will save us" argument. Despite the "tools will save 
us" argument being unpopular, I think it is unwise for an average 
developer to approach XMLNS without proper tools.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

Sam Ruby wrote:
New abstract:
  Given that common practice is to include this element, making it
  mandatory makes things clearer to both people who are producing
  consuming tools based on the spec, and people who are producing new
  feeds based on copy and paste.
New spec text:
  The xhtml:div element itself MUST NOT be considered part of the
  content.
I find it a bit problematic to use "common practice" in Atom feeds as 
justification for spec changes. Let's make the spec as clear and 
simple as possible. If this is in conflict with common usage in 
experimental Atom feeds, so be it.
That is consistent with your prior statement that you don't believe that 
implementation issues should affect the format:

http://www.imc.org/atom-syntax/mail-archive/msg12699.html
Yes, I want a spec that is simple. I also want a spec that average 
people can implement simply and correctly.

We have seen on this very mailing list people who have an above average 
understanding of XML trip over this particular area numerous times.

I am not content to create a format for which the answers to such common 
user errors is "so be it".
However, what is the problem with people using a DIV element inside 
SUMMARY and the CONTENT element if they wish to do so?

By the way, I have read the thing you wrote about things like planet 
copy the contents and put it in their own DIV element but if that is how 
they are going to treat Atom, Atom will not be solving anything and will 
just be another RSS I guess.

Authors who do copy and paste and others should always validate their 
feed. I guess the feed validator could flag elements that are in the 
Atom namespace and should not be there according to the latest updates 
of the Atom namespace.

Eventually, I guess it is about getting the major weblog systems and 
companies to get their implementation right. The Atom WG and other 
people should also provide tutorials on how to create Atom feeds and how 
to make sure everything works as it should.

--
 Anne van Kesteren
 

PaceXhtmlNamespaceDiv

[Antone Roundy]

I've updated the examples as follows:
Removed the style attribute from the div in one--if the div is not part 
of the content, it doesn't make sense to me allow it to control styling 
of the content.  Yeah, I wrote the original example, but I hadn't 
thought through everything clearly enough yet.

Added an example that presumes that the XHTML namespace has already 
been bound to the prefix "xhtml".

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:
That is consistent with your prior statement that you don't believe that 
implementation issues should affect the format:

http://www.imc.org/atom-syntax/mail-archive/msg12699.html
What I said is that very *specific* implementation issue shouldn't 
affect the format. Please cite correctly. I also posted the following 
clarification in 
:

"OK, I'll try to rephrase: changing the protocol format because one 
implementor says that this makes it easier to implement IMHO is a bad 
idea. Of course things look differently if this issue affects more 
platforms/parsers/toolkits.

So yes, more information is needed."
Yes, I want a spec that is simple.  I also want a spec that average 
people can implement simply and correctly.

We have seen on this very mailing list people who have an above average 
understanding of XML trip over this particular area numerous times.

I am not content to create a format for which the answers to such common 
user errors is "so be it".
Nor am I. The question is what's the best way to enhance the spec. One 
alternative suggestion was made by Martin Dürst in 
:

"Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an 
element as the content of the  element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way."
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
Sam Ruby wrote:
That's what I want to change.  I've updated the Pace to make this 
clearer.  I replaced the abstract completely, and added one sentence 
to the proposal.

New abstract:
  Given that common practice is to include this element, making it
  mandatory makes things clearer to both people who are producing
  consuming tools based on the spec, and people who are producing new
  feeds based on copy and paste.
New spec text:
  The xhtml:div element itself MUST NOT be considered part of the
  content.
I find it a bit problematic to use "common practice" in Atom feeds as 
justification for spec changes. Let's make the spec as clear and simple 
as possible. If this is in conflict with common usage in experimental 
Atom feeds, so be it.
That is consistent with your prior statement that you don't believe that 
implementation issues should affect the format:

http://www.imc.org/atom-syntax/mail-archive/msg12699.html
Yes, I want a spec that is simple.  I also want a spec that average 
people can implement simply and correctly.

We have seen on this very mailing list people who have an above average 
understanding of XML trip over this particular area numerous times.

I am not content to create a format for which the answers to such common 
user errors is "so be it".

- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:
That's what I want to change.  I've updated the Pace to make this 
clearer.  I replaced the abstract completely, and added one sentence to 
the proposal.

New abstract:
  Given that common practice is to include this element, making it
  mandatory makes things clearer to both people who are producing
  consuming tools based on the spec, and people who are producing new
  feeds based on copy and paste.
New spec text:
  The xhtml:div element itself MUST NOT be considered part of the
  content.
I find it a bit problematic to use "common practice" in Atom feeds as 
justification for spec changes. Let's make the spec as clear and simple 
as possible. If this is in conflict with common usage in experimental 
Atom feeds, so be it.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Henri Sivonen wrote:
On Feb 9, 2005, at 15:28, Sam Ruby wrote:
Here's the key question.  Consider the following XML fragment:
  Hey, 
this is my space, if I want to run a picture of a chair I can. And 
it’s a nice chair.

Given this fragment, what is the value of the summary?  Is the div 
element to be considered part of the format (and therefore not part of 
the summary).  Or is the div element to be considered part of the 
summary itself.
The div is part of the summary according to current spec text.
That's what I want to change.  I've updated the Pace to make this 
clearer.  I replaced the abstract completely, and added one sentence to 
the proposal.

New abstract:
  Given that common practice is to include this element, making it
  mandatory makes things clearer to both people who are producing
  consuming tools based on the spec, and people who are producing new
  feeds based on copy and paste.
New spec text:
  The xhtml:div element itself MUST NOT be considered part of the
  content.
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 9, 2005, at 15:28, Sam Ruby wrote:
Here's the key question.  Consider the following XML fragment:
  Hey, 
this is my space, if I want to run a picture of a chair I can. And 
it’s a nice chair.

Given this fragment, what is the value of the summary?  Is the div 
element to be considered part of the format (and therefore not part of 
the summary).  Or is the div element to be considered part of the 
summary itself.
The div is part of the summary according to current spec text.
Assume for the moment that it is part of the summary.  You can give 
the author a bit of poetic license and say that this is valid.
It is correct, because a div can correctly be a child of div and the 
content model of Text constructs is defined to be the content model of 
div.

If you look at Tim's feed, you will see that a similar approach is 
used for syndicating content.  The validity of that is not quite so 
clear.
It is correct from the syntactic point of view, although I understand 
your point that it may not be part of what the ongoing CMS treats as 
content internally.

Now consider what happens when data is resyndicated (Planet XML, for 
example).  If such tools add a div element,
Your argument is based on the assumption that resyndicators need or 
want such a div. But why would such an aggregator add the div? While a 
CMS may successfully engage in string concatenation, because it 
internally restricts the string serialization of the content, 
resyndicators cannot rely on a particular serialization and, therefore, 
must not attempt grab a substring of unparsed XML source and try to 
concatenate it into an unparsed string template. Since resyndicators 
need to deal with all of XMLNS, why would they include extra divs that 
are convenient for string concatenators? The serialization code of 
resyndicators has to deal with synthesizing namespace declarations 
and/or namespace prefixes anyway, so I don't see how  resyndicators 
would benefit from adding an extra wrapper.

Now consider what happens if tools that implement the protocol do 
likewise.  Get a feed, modify an entry, and POST it.  Over time, you 
will end up with telescoping divs.
Again, you are assuming XHTML-capable clients want to behave like tag 
soup concatenators. Why not use type='HTML' for that?

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Sam Ruby wrote:
> Now consider what happens when data is resyndicated (Planet XML, for
> example).  If such tools add a div element, and the div element is
> considered part of the summary/content, then they are technically wrong.
>  But this will likely go unnoticed for a while as visually the results
> appear correct.
>
> Now consider what happens if tools that implement the protocol do
> likewise.  Get a feed, modify an entry, and POST it.  Over time, you
> will end up with telescoping divs.
>
> The solution that some will likely come up with will be to ignore
> enclosing divs.
Hmm.. considering DIV as being part of the summary is a bit like saying 
the  element in the content following example is part of the 
enclosing content... it just doesn't make sense.


  

  

  

  

If a DIV is required for XHTML content, tools working with Atom should 
deal with it accordingly and properly without us having to specify a 
special handling case for XHTML content that does not apply to any other 
type of XML content.

If tools want to add additional div's in addition to the one in the 
content/summary, so be it, it is entirely up to that up to that 
particular tool to do implement its own brand of silliness.

- James M Snell

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Martin Duerst wrote:
At 22:59 05/02/08, Julian Reschke wrote:
 >http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
I have looked at this pace only just very recently, after
following the discussion. So I first want to make sure I
get the current status of this proposal right.
As I currently read it, it does:
1) Require an  as the only direct child of content of type XHTML
2) Not limit the placement of namespace declarations in any way above
   and beyond those given in the Namespace spec.
3) Not require any specific namespace prefixes.
If 2) and 3) are correct, I can live with this proposal. Anything
changing 2) or 3), as may have been previously in this Pace, would
get something like a -2 from me. Specs, in particular such fundamental
ones as XML Namespaces, are there to be used as is, not to be tweaked.
Agreed.
As for 1), I could live with it, but the rationale given for it in the
current version says:
"Given that even we often forget when writing examples to declare
 the XHTML namespace for XHTML text constructs and content elements,
 it seems likely that people producing actual feeds will forget
 to do so unless the requirement to do so is stated prominently
 and unambiguously."
This doesn't seem to match the proposal, where Namespace declarations
are only used in the examples, but not mentioned in the text.
So while (as said above) I can live with 1), insisting on 1) without
a better rationale doesn't seem to make sense to me.
If the concern expressed in the rationale is important (and I can
agree it is), then addressing this concern can be done in less
constricting ways, i.e. by replacing the requirement for a 
with something like:
Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an 
element as the content of the  element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way.
Here's the key question.  Consider the following XML fragment:
  Hey, 
this is my space, if I want to run a picture of a chair I can. And it’s 
a nice chair.

Given this fragment, what is the value of the summary?  Is the div 
element to be considered part of the format (and therefore not part of 
the summary).  Or is the div element to be considered part of the 
summary itself.

Assume for the moment that it is part of the summary.  You can give the 
author a bit of poetic license and say that this is valid.  If you look 
at Tim's feed, you will see that a similar approach is used for 
syndicating content.  The validity of that is not quite so clear.

Now consider what happens when data is resyndicated (Planet XML, for 
example).  If such tools add a div element, and the div element is 
considered part of the summary/content, then they are technically wrong. 
 But this will likely go unnoticed for a while as visually the results 
appear correct.

Now consider what happens if tools that implement the protocol do 
likewise.  Get a feed, modify an entry, and POST it.  Over time, you 
will end up with telescoping divs.

The solution that some will likely come up with will be to ignore 
enclosing divs.

Some may do this.  Some may not.
Now assume for the moment that the div is not part of the summary.
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Eric Scheid]

On 9/2/05 3:39 PM, "Martin Duerst" <[EMAIL PROTECTED]> wrote:

> Note: It is important to make sure that correct namespace declarations
> for XHTML are present. One way to do this is by using an 
> element as the content of the  element and specifying
> the XHTML namespace on that div element. Here are some examples:
> ... [use proposed examples]
> There are other ways to declare the namespace URI for XHTML content;
> this specification does not limit the placement of such declarations
> in any way.

+1

Re: PaceXhtmlNamespaceDiv

[Martin Duerst]

At 22:59 05/02/08, Julian Reschke wrote:
>http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
I have looked at this pace only just very recently, after
following the discussion. So I first want to make sure I
get the current status of this proposal right.
As I currently read it, it does:
1) Require an  as the only direct child of content of type XHTML
2) Not limit the placement of namespace declarations in any way above
   and beyond those given in the Namespace spec.
3) Not require any specific namespace prefixes.
If 2) and 3) are correct, I can live with this proposal. Anything
changing 2) or 3), as may have been previously in this Pace, would
get something like a -2 from me. Specs, in particular such fundamental
ones as XML Namespaces, are there to be used as is, not to be tweaked.
As for 1), I could live with it, but the rationale given for it in the
current version says:
"Given that even we often forget when writing examples to declare
 the XHTML namespace for XHTML text constructs and content elements,
 it seems likely that people producing actual feeds will forget
 to do so unless the requirement to do so is stated prominently
 and unambiguously."
This doesn't seem to match the proposal, where Namespace declarations
are only used in the examples, but not mentioned in the text.
So while (as said above) I can live with 1), insisting on 1) without
a better rationale doesn't seem to make sense to me.
If the concern expressed in the rationale is important (and I can
agree it is), then addressing this concern can be done in less
constricting ways, i.e. by replacing the requirement for a 
with something like:
Note: It is important to make sure that correct namespace declarations
for XHTML are present. One way to do this is by using an 
element as the content of the  element and specifying
the XHTML namespace on that div element. Here are some examples:
... [use proposed examples]
There are other ways to declare the namespace URI for XHTML content;
this specification does not limit the placement of such declarations
in any way.
Regards, Martin.

Re: PaceXhtmlNamespaceDiv

[Robert Sayre]

Julian Reschke wrote:
- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."
I'm sorry, that is ridiculous.
Robert Sayre

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

Sam Ruby wrote:
Content type="XML" should be able to hold any type.  type="XHTML" should 
be a valid XHTML fragment.
I hope type="XML" is just an example?
(I still think we should revert it back to TYPE and MODE where MODE is 
optional and TYPE has a fixed value of "text/plain".)

--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
"- Requiring the namespace declaration on a particular element means 
(a) profiling XMLNS, (b) defeating potential space optimizations by 
having the namespace declaration only once, and (c) breaks XML 
toolkits that do not provide full control over where namespace 
declarations appear.
Nothing in this pace requires such a declaration.
"When a Text construct or atom:content's type is "XHTML", require it to 
have a single xhtml:div as a child, and require that div to declare the 
XHTML namespace."

Am I looking at the wrong pace? 
(<http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv>)
I have just updated the Pace to remove from the abstract text which is 
no longer reflected in the proposal.

- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 8, 2005, at 15:59, Julian Reschke wrote:
"When a Text construct or atom:content's type is "XHTML", require it 
to have a single xhtml:div as a child, and require that div to declare 
the XHTML namespace."

Am I looking at the wrong pace? 
(<http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv>)
The abstract no longer matches the proposal. This seems to cause 
confusion.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Eric Scheid wrote:
On 8/2/05 11:56 PM, "Julian Reschke" <[EMAIL PROTECTED]> wrote:

- if this pace gets accepted, I would ask for the same DIV container
element for HTML content for reasons of symmetry."

I thought with @type="HTML" the content gets escaped and thus there is
nothing to put into a namespace.
Yes.
I think the issue here is that the Pace combines different requirements 
(a: let's have a single container element, and b: let's force people to 
explicitly declare their XHTML ns in a single place). It would be good 
for the discussion if we could agree about what is still in scope, and 
what in particular we want to achieve.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 8, 2005, at 15:44, Sam Ruby wrote:
What Tim is syndicating does not match the content on his site.  
Without this Pace, the div element would need to be considered part of 
the content.
What's the harm?
 However, a globally scoped XHTML namespace declaration will require 
every xhtml tag to be explicitly namespaced.
Or the Atom tags to be colonified.
Are you suggesting that the following would need to be required for 
symmetry?

  
 ... 
Suggesting this seems petty.
I agree. However, I have similar sentiments towards requiring the div 
with XHTML.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Bill de hÓra wrote:
Julian Reschke wrote:
 Below are some comments that I just added to the Pace:
"- Requiring the namespace declaration on a particular element means 
(a) profiling XMLNS, 

I don't have a problem with this. Taking XMLNS warts and all cause more 
problems that it solves.
Well, it also enables us to relatively painlessly combine Atom and XHTML 
in the same document.

(b) defeating potential space optimizations by having the namespace 
declaration only once, and 

Do you have a sense of how serious not allowing these potential 
optimizations is?
I just tried with Tim's feed, and I am getting a reduction of around 4%. 
Your mileage may vary a log depending on typical length and structure of 
content.

(c) breaks XML toolkits that do not provide full control over where 
namespace declarations appear.
They sound like dysfunctional toolkits. Can you name some (ie it might 
be persuasive if it came to light that a scad of PHP users were left 
high and dry).
I wrote one myself back when Xerces' serializer was broken in regards of 
namespace handling. For the same reasons, similar serializers may exist 
elsewhere.

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."

+1 to that symmetry.
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:
Nothing changes for Tim, he can continue to produce the output he's 
producing currently.

What Tim is syndicating does not match the content on his site.  Without 
this Pace, the div element would need to be considered part of the content.
What difference does this make in practice? HTML defines DIV as...
"These elements define content to be inline (SPAN) or block-level (DIV) 
but impose no other presentational idioms on the content."

(<http://www.w3.org/TR/html401/struct/global.html#edef-DIV>)
  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.

Whether something is easier to read seems to be a matter of taste: I 
certainly prefer a globally scoped XHTML namespace declaration, and no 
additional DIV elements.

Fair.  However, a globally scoped XHTML namespace declaration will 
require every xhtml tag to be explicitly namespaced.
(unless we make it the default namespace, which usually won't make sense).
"- Requiring the namespace declaration on a particular element means 
(a) profiling XMLNS, (b) defeating potential space optimizations by 
having the namespace declaration only once, and (c) breaks XML 
toolkits that do not provide full control over where namespace 
declarations appear.

Nothing in this pace requires such a declaration.
"When a Text construct or atom:content's type is "XHTML", require it to 
have a single xhtml:div as a child, and require that div to declare the 
XHTML namespace."

Am I looking at the wrong pace? 
(<http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv>)

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."

Are you suggesting that the following would need to be required for 
symmetry?

  <div> ... </div>
Yes.
Suggesting this seems petty.
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 8, 2005, at 15:14, Bill de hÓra wrote:
Julian Reschke wrote:
 Below are some comments that I just added to the Pace:
"- Requiring the namespace declaration on a particular element means 
(a) profiling XMLNS,
I don't have a problem with this. Taking XMLNS warts and all cause 
more problems that it solves.
Restricting XMLNS is no longer on the table.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Eric Scheid]

On 8/2/05 11:56 PM, "Julian Reschke" <[EMAIL PROTECTED]> wrote:

> - if this pace gets accepted, I would ask for the same DIV container
> element for HTML content for reasons of symmetry."

I thought with @type="HTML" the content gets escaped and thus there is
nothing to put into a namespace.

e.

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
Sam Ruby wrote:
Bill de hÓra wrote:
Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
I'd like to see a concrete example where this is a problem. As far as I 
can tell, the content construct itself can be considered the container, 
so whether or not a mandatory DIV element is present, there will always 
be a useable container element.

  2) Tim (who uses string concatenation) will have to do more work.
Nothing changes for Tim, he can continue to produce the output he's 
producing currently.
What Tim is syndicating does not match the content on his site.  Without 
this Pace, the div element would need to be considered part of the content.

  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
Whether something is easier to read seems to be a matter of taste: I 
certainly prefer a globally scoped XHTML namespace declaration, and no 
additional DIV elements.
Fair.  However, a globally scoped XHTML namespace declaration will 
require every xhtml tag to be explicitly namespaced.

  3) More feeds will be invalid (content in atom namespace)
Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, 
the container markup format is just dandy, but the content they carry 
is potentially trashed. If we condone default namespaces this is what 
we can expect to happen. We discussed warning people about this 
broken piece of XML technology last year and it was punted to an 
Implementors Guide - I'm somewhat unsympathetic now if we find 
ourselves bitten.
Content type="XML" should be able to hold any type.  type="XHTML" should 
be a valid XHTML fragment.

Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.

atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.
Yes, but there are many other things people may get wrong when producing 
Atom. In particular, I would tend to trust those who do generate XHTML 
instead of HTML to get namespace declarations right as well.
I have personally seen such invalid feeds.  In large quanties.  I've 
worked with the individuals that have produced such feeds, but 
ultimately such an approach doesn't scale.

Below are some comments that I just added to the Pace:
"- Requiring the namespace declaration on a particular element means (a) 
profiling XMLNS, (b) defeating potential space optimizations by having 
the namespace declaration only once, and (c) breaks XML toolkits that do 
not provide full control over where namespace declarations appear.
Nothing in this pace requires such a declaration.
- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."
Are you suggesting that the following would need to be required for 
symmetry?

  
 ... 
Suggesting this seems petty.
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
Sam Ruby wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.
Same here: -1
Can I get one of you three to mock up what Tim's feed should look like?
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
- Sam Ruby
I'm not sure I understand this request. We're not asking Tim or anybody 
else not to use  elements, we're asking not to be forced by the 
spec to select a specific way to emit XHTML when many others do as well.

So, this is a -1 on forcing feed creators to use a very specific 
serialization format.
This Pace does *not* force feed creators to use a very specific feed format.
Anne had this right... if this Pace is adopted, then the div is part of 
the format.  Otherwise, it is part of the content.

In other words, if Tim's content has a  element that he wishes to 
syndicate, he would simply nest that div.  This would be rare.

As it stands, the content that Tim is syndicating does not match the 
content on his site.

- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Bill de hÓra]

Julian Reschke wrote:
 Below are some comments that I just added to the Pace:
"- Requiring the namespace declaration on a particular element means (a) 
profiling XMLNS, 
I don't have a problem with this. Taking XMLNS warts and all cause more 
problems that it solves.


(b) defeating potential space optimizations by having 
the namespace declaration only once, and 
Do you have a sense of how serious not allowing these potential 
optimizations is?


(c) breaks XML toolkits that do 
not provide full control over where namespace declarations appear.
They sound like dysfunctional toolkits. Can you name some (ie it might 
be persuasive if it came to light that a scad of PHP users were left 
high and dry).

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."
+1 to that symmetry.
cheers
Bill

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:
Bill de hÓra wrote:
Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
I'd like to see a concrete example where this is a problem. As far as I 
can tell, the content construct itself can be considered the container, 
so whether or not a mandatory DIV element is present, there will always 
be a useable container element.

  2) Tim (who uses string concatenation) will have to do more work.
Nothing changes for Tim, he can continue to produce the output he's 
producing currently.

  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
Whether something is easier to read seems to be a matter of taste: I 
certainly prefer a globally scoped XHTML namespace declaration, and no 
additional DIV elements.

  3) More feeds will be invalid (content in atom namespace)

Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.

Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.

atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.
Yes, but there are many other things people may get wrong when producing 
Atom. In particular, I would tend to trust those who do generate XHTML 
instead of HTML to get namespace declarations right as well.

Below are some comments that I just added to the Pace:
"- Requiring the namespace declaration on a particular element means (a) 
profiling XMLNS, (b) defeating potential space optimizations by having 
the namespace declaration only once, and (c) breaks XML toolkits that do 
not provide full control over where namespace declarations appear.

- if this pace gets accepted, I would ask for the same DIV container 
element for HTML content for reasons of symmetry."

Best regards, Julian


--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 22:58, Sam Ruby wrote:
If you are opposed to this pace, then what div element?
If the pace does not get through, it is still permissible to put a div 
in there as part of the content. In fact, either way it is permissible 
to add meaningless extra divs, since a div can nest in a div.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 8, 2005, at 07:03, Henri Sivonen wrote:
On Feb 8, 2005, at 01:55, Sam Ruby wrote:
Can I get one of you three to mock up what Tim's feed should look 
like?

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The Mouse BT from some 
outfit
...
OR (even less impact on string concatenators):

...
 
...
  I was in the drugstore picking up 
a prescription and wandered into the computer section, where I found 
myself impulse-buying The 
Mouse BT from some outfit
...

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 23:21, Sam Ruby wrote:
  1) Graham (who uses proper XML tools) will have to do more work.
Which tools? How much more? One loop more?
(FWIW, I do not consider Apple's Core Foundation "XML parser" a proper 
XML tool.)

  2) Tim (who uses string concatenation) will have to do more work.
When I did a string concatenation implementation, using colonified 
names was not a big deal.

  5) For some combinations of clients and servers, entries produced
 via an HTTP POST will end up with multiple s.
I can anticipate that happening either way.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Sam Ruby wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv

-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.

Same here: -1

Can I get one of you three to mock up what Tim's feed should look like?
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
- Sam Ruby
I'm not sure I understand this request. We're not asking Tim or anybody 
else not to use  elements, we're asking not to be forced by the 
spec to select a specific way to emit XHTML when many others do as well.

So, this is a -1 on forcing feed creators to use a very specific 
serialization format.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 8, 2005, at 01:55, Sam Ruby wrote:
Can I get one of you three to mock up what Tim's feed should look like?

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The 
Mouse BT from some outfit
...

OR

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The Mouse BT from some 
outfit
...

OR

...
 
...
  I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying The Mouse BT from some 
outfit
...

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Eric Scheid]

> PaceXhtmlNamespaceDiv

+1 

Re: PaceXhtmlNamespaceDiv

[Bill de hÓra]

Sam Ruby wrote:
Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.
>
atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.
Agreed (but we have already decided to allow that possibility at the 
container level). Still +1.

cheers
Bill

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Bill de hÓra wrote:
Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
  2) Tim (who uses string concatenation) will have to do more work.
  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
  3) More feeds will be invalid (content in atom namespace)
Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.
Perhaps I overreached with the word "invalid", but I am of the opinion 
that if the type is XHTML that the content should be an xthml fragment.

atom:b and atom:strong elements are examples of things which one would 
not expect to find in xhtml.

- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Julian Reschke wrote:
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.
Same here: -1
Can I get one of you three to mock up what Tim's feed should look like?
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Bill de hÓra]

Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
  2) Tim (who uses string concatenation) will have to do more work.
  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
  3) More feeds will be invalid (content in atom namespace)
Perhaps I misunderstand... but this shouldn't result in invalid Atom 
feeds ever - content areas should be able to hold any-namespace not 
any-namespace-atom-namespace. Worst case is mangled content when the 
content is lifted out using namespace aware tools. In other words, the 
container markup format is just dandy, but the content they carry is 
potentially trashed. If we condone default namespaces this is what we 
can expect to happen. We discussed warning people about this broken 
piece of XML technology last year and it was punted to an Implementors 
Guide - I'm somewhat unsympathetic now if we find ourselves bitten.

I'm +1 on this pace, sometimes a judicious hack is the right thing to 
do. I suspect it could result in  nesting - call it gut feeling 
(it's an escaping mechanism after all).

cheers
Bill

Re: PaceXhtmlNamespaceDiv

[Roger B.]

I'm +1 when wearing my aggregator hat, and indifferent from a
publishing perspective.

--
Roger Benningfield
JournURL

Re: PaceXhtmlNamespaceDiv

[Julian Reschke]

Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv

-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.
Same here: -1
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv

[Robert Sayre]

Sam Ruby wrote:
I can easily sit back and adopt a "wait and see" and "I told you so" 
attitude, but by now it should be obvious that I care too much about the 
success of this format and protocol to do that.

After watching this WG fail to communicate clearly on this matter, and 
make a variety of arcane XML serialization mistakes in the course of 
discussion, it's clear to me that Sam is right.

+1 to PaceXhtmlNamespaceDiv
Robert Sayre

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Anne van Kesteren wrote:
Sam Ruby wrote:
Ok, now that I'm thinking about this more, I'm changing my initial 
+0 to +1.  This just makes sense.  There does need to be a container 
for the XHTML and div is a solid, logical choice.  I don't think it 
should matter where the xmlns is declared... any ancestor element 
will do.

I'm still -1. But I was wondering, why only ancestor elements? 
Wouldn't the most logical thing for "string based generators" be to 
apply it on the DIV element?
I'm confused.  If you are opposed to this pace, then what div element?
That was a question in reply to what James wrote. It appeared to be an 
error.

It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the  element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?
If the page is adopted, which I hope not, it MUST NOT be part of the 
content. If the page is not adopted it MUST be part of the content.
I can easily sit back and adopt a "wait and see" and "I told you so" 
attitude, but by now it should be obvious that I care too much about the 
success of this format and protocol to do that.

If this Pace is not adopted, the following predictions can be made:
  1) Graham (who uses proper XML tools) will have to do more work.
  2) Tim (who uses string concatenation) will have to do more work.
  3) More feeds will be harder to read (that's why I asked you to
 experiment with alternate serializations.
  3) More feeds will be invalid (content in atom namespace)
  4) More feeds will be incorrect (in the sense that Tim's feed does
 accurately reflect the content of his entries).
  5) For some combinations of clients and servers, entries produced
 via an HTTP POST will end up with multiple s.
Meanwhile, now that the location where the namespace can be declared 
details have been removed from this pace, Henri can continue to do a 
DOM-to-DOM copy.

I stand by my original statements:
  There are cases where explicit is better than implicit.
  Given that common practice is to include this element, making it
  mandatory makes things clearer to both people who are producing
  consuming tools based on the spec, and people who are producing new
  feeds based on copy and paste.
- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 22:44, James M Snell wrote:
Nah, I don't buy it.  XHTML is just a special case of an XML content
Atom has chosen to treat type='XHTML' (as opposed to 
type='application/xtml+xml') as a special case.

wouldn't make any sense (under the assumption that the  
element is top level container) for us to do:


  
...
  
  
...
  

By that logic, you'd have to include the 'html', 'head', 'title' and 
'body' XHTML elements as well. See http://macsanomat.com/atom for an 
example of that. (0.3 was silent on subsetting the XHTML document, so 
logically I had to assume it was not allowed, although the 
ViewSourceClan thought it was.)

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Anne van Kesteren wrote:
James M Snell wrote:
Nah, I don't buy it.  XHTML is just a special case of an XML content 
and if we were embedding some XML data (say an atom:feed) it wouldn't 
make any sense (under the assumption that the  element is 
top level container) for us to do:


  
...
  
  
...
  


I do not follow this example.
The point is that  should not be viewed as the root element 
for contained XML.  The XML content should be able to stand on it's own, 
indepedently of the content or text construct element as well-formed XML.


In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.

So you want a DIV as wrapper element for TITLE and similar elements as 
well?


For Text construct and Content, if XHTML is used, there should be a DIV. 
 If someone wants to use XHTML for title, then yes, they should use a 
DIV. Otherwise, they can use plain text.


- James M Snell

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

Sam Ruby wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 
to +1.  This just makes sense.  There does need to be a container for 
the XHTML and div is a solid, logical choice.  I don't think it 
should matter where the xmlns is declared... any ancestor element 
will do.
I'm still -1. But I was wondering, why only ancestor elements? 
Wouldn't the most logical thing for "string based generators" be to 
apply it on the DIV element?
I'm confused.  If you are opposed to this pace, then what div element?
That was a question in reply to what James wrote. It appeared to be an 
error.


It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the  element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?
If the page is adopted, which I hope not, it MUST NOT be part of the 
content. If the page is not adopted it MUST be part of the content.

--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Anne van Kesteren wrote:
James M Snell wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 
to +1.  This just makes sense.  There does need to be a container for 
the XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.
I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for "string based generators" be to apply it on 
the DIV element?
I'm confused.  If you are opposed to this pace, then what div element?
It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the  element is part of the 
format or part of the content?  Should aggregators copy it?  When an 
Atom entry is POSTed to a blog, is the div part of the content?

- Sam Ruby

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

James M Snell wrote:
Nah, I don't buy it.  XHTML is just a special case of an XML content and 
if we were embedding some XML data (say an atom:feed) it wouldn't make 
any sense (under the assumption that the  element is top 
level container) for us to do:


  
...
  
  
...
  

I do not follow this example.

In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.
So you want a DIV as wrapper element for TITLE and similar elements as well?
--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

For the record, the additional loop that the div would save in a 
DOM-based client is not that hard:

copyLangAndBase(atomTextCostruct, targetDivInTemplate);
for (Node n = atomTextCostruct.getFirstChild(); n != null; n = 
n.getNextSibling()) {
	targetDivInTemplate.appendChild(templateXhtmlDocument.importNode(n, 
true));
}

Is that too much to ask from clients?
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Antone Roundy]

On Monday, February 7, 2005, at 01:09  PM, Henri Sivonen wrote:
On Feb 7, 2005, at 21:52, Antone Roundy wrote:
+1, but I wouldn't object to a variant that required either the DIV 
with a namespace declaration OR for the namespace to be declared in 
 or before .  Examples of what I'd think was 
acceptable:


...
This is bold
This is against the Pace. Are you really supporting the pace?
Yes, while saying that I would be satisfied with this too--as long as 
the namespace declaration doesn't occur inside  unless in a 
DIV that contains everything else that's in .

OR
This is bold
This is against the Pace, too.
Yep.  Same answer.
OR
This is bold
This one is against the pace as well. Also, the 'b' element would be 
in the same namespace as 'content', which seems wrong.
Gaah!  I left off the  and accidentally put a "/" in the end of 
the  tag.  I meant This is 
bold.  One of those mistakes I could understand, 
but how did I manage to do both at once?

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Nah, I don't buy it.  XHTML is just a special case of an XML content and 
if we were embedding some XML data (say an atom:feed) it wouldn't make 
any sense (under the assumption that the  element is top 
level container) for us to do:


  
...
  
  
...
  

In my opinion, the XML contained in the content or text element should 
be capable of standing alone outside of the content element as a 
well-formed document and XHTML is just a special case of XML content.

- James M Snell
Henri Sivonen wrote:
On Feb 7, 2005, at 22:18, James M Snell wrote:
There does need to be a container for the XHTML and div is a solid, 
logical choice.

The container is the Atom Text construct itself!

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

James M Snell wrote:
Yes, sorry I wasn't clear.  Not *only* on ancestor elements. any of the 
following cases should be allowed.

[snip]
And surely || so people who append strings together can 
 do so easily.

I still wonder what the advantage of this conainer is. Especially since, 
as pointed out, the CONTENT element already is the container.

--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Yes, sorry I wasn't clear.  Not *only* on ancestor elements. any of the 
following cases should be allowed.


  

  

  


  

  

  


  

  

  


  

  

  

- James M Snell
Anne van Kesteren wrote:
James M Snell wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 
to +1.  This just makes sense.  There does need to be a container for 
the XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.

I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for "string based generators" be to apply it on 
the DIV element?

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 22:18, James M Snell wrote:
There does need to be a container for the XHTML and div is a solid, 
logical choice.
The container is the Atom Text construct itself!
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

James M Snell wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 to 
+1.  This just makes sense.  There does need to be a container for the 
XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.
I'm still -1. But I was wondering, why only ancestor elements? Wouldn't 
the most logical thing for "string based generators" be to apply it on 
the DIV element?

--
 Anne van Kesteren
 

Re: PaceXhtmlNamespaceDiv

[James M Snell]

Ok, now that I'm thinking about this more, I'm changing my initial +0 to 
+1.  This just makes sense.  There does need to be a container for the 
XHTML and div is a solid, logical choice.  I don't think it should 
matter where the xmlns is declared... any ancestor element will do.

- James M Snell
Antone Roundy wrote:
+1, but I wouldn't object to a variant that required either the DIV with 
a namespace declaration OR for the namespace to be declared in  
or before .  Examples of what I'd think was acceptable:


...
This is bold
OR
This is bold
OR
This is bold
Here's what I think is just plain ugly and shouldn't be allowed:
This is bold
OR
This is bold

Re: PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 21:52, Antone Roundy wrote:
+1, but I wouldn't object to a variant that required either the DIV 
with a namespace declaration OR for the namespace to be declared in 
 or before .  Examples of what I'd think was 
acceptable:


...
This is bold
This is against the Pace. Are you really supporting the pace?
OR
This is bold
This is against the Pace, too.
OR
This is bold
This one is against the pace as well. Also, the 'b' element would be in 
the same namespace as 'content', which seems wrong.

Here's what I think is just plain ugly and shouldn't be allowed:
This is bold
IMO, that should be allowed. Atom has no business in restricting the 
syntactic sugar provided by Namespaces in XML.

OR
This is bold
IMO, this on should be allowed on the same grounds.
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv

[Anne van Kesteren]

Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.

--
 Anne van Kesteren
 <http://annevankesteren.nl/>

Re: PaceXhtmlNamespaceDiv

[Graham]

On 7 Feb 2005, at 7:38 pm, Sam Ruby wrote:
Since then a number of folks (myself included) expressed support for 
this Pace, I reopened it with an email to the list, and I will now 
reiterate my support now with a +1.

There are a number of issues that this resolves, such as whether the 
div element itself is to be considered part of the content in protocol 
POST methods.  If they are not, you will tend over time to see 
multiple such wrappings.
+1, and not just because it will make my life easier.
Graham

PaceXhtmlNamespaceDiv

[Antone Roundy]

+1, but I wouldn't object to a variant that required either the DIV 
with a namespace declaration OR for the namespace to be declared in 
 or before .  Examples of what I'd think was 
acceptable:


...
This is bold
OR
This is bold
OR
This is bold
Here's what I think is just plain ugly and shouldn't be allowed:
This is bold
OR
This is bold

Re: PaceXhtmlNamespaceDiv

[Sam Ruby]

Henri Sivonen wrote:
On Feb 7, 2005, at 19:50, Paul Hoffman wrote:
Even if you sent in a +1, 0, or -1 previously on a particular Pace, 
send it in again. Hopefully, add a short or long comment on why you 
feel it should or should not be considered part of the Atom core.
-1 on PaceXhtmlNamespaceDiv
The div is an additional container inside the Text construct container. 
The main purpose of the div is to save one for loop in a 
document-tree/pull-based client or, alternatively, to give a false sense 
of correctness in tag soup concatenation-based clients. IMO, neither 
rationale warrants a meaningless element inside a Text construct.

(Noting that the Pace was retracted by the original author.)
It was retracted due to a perceived lack of interest - at that point it 
was a two party dialog between yourself and that author.

Since then a number of folks (myself included) expressed support for 
this Pace, I reopened it with an email to the list, and I will now 
reiterate my support now with a +1.

There are a number of issues that this resolves, such as whether the div 
element itself is to be considered part of the content in protocol POST 
methods.  If they are not, you will tend over time to see multiple such 
wrappings.

-Sam Ruby

PaceXhtmlNamespaceDiv

[Henri Sivonen]

On Feb 7, 2005, at 19:50, Paul Hoffman wrote:
Even if you sent in a +1, 0, or -1 previously on a particular Pace, 
send it in again. Hopefully, add a short or long comment on why you 
feel it should or should not be considered part of the Atom core.
-1 on PaceXhtmlNamespaceDiv
The div is an additional container inside the Text construct container. 
The main purpose of the div is to save one for loop in a 
document-tree/pull-based client or, alternatively, to give a false 
sense of correctness in tag soup concatenation-based clients. IMO, 
neither rationale warrants a meaningless element inside a Text 
construct.

(Noting that the Pace was retracted by the original author.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv posted

[Roger B.]

> Of course things look differently if this issue affects more
> platforms/parsers/toolkits.

It does. I'm in a similar boat.

On the other hand, since I'm going to be forced to parse Atom 0.3
until the end of time, and some 0.3 feeds don't use the div, it really
doesn't make a difference to me. I'm gonna be looping over and
xmlChildren array no matter what.

Requiring the div could certainly make life easier for those who are
going to restrict parsing to Atom 1.0, though.

--
Roger Benningfield
http://admin.support.journurl.com/

Re: PaceXhtmlNamespaceDiv posted

[Asbjørn Ulsberg]

On Sun, 30 Jan 2005 17:57:57 +, Graham <[EMAIL PROTECTED]> wrote:
I'm in favor of it. My current parser doesn't let me pull out "all
childen of element x" in one go, so I have to step through in a really
hacky way. With this I can just grab the div.
You can't grab 'atom:content/*[1]' or something similar?
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: PaceXhtmlNamespaceDiv posted

[Henri Sivonen]

On Jan 30, 2005, at 21:06, Julian Reschke wrote:
OK, I'll try to rephrase: changing the protocol format because one 
implementor says that this makes it easier to implement IMHO is a bad 
idea. Of course things look differently if this issue affects more 
platforms/parsers/toolkits.
FWIW, one could let WebCore see the Atom Text construct element without 
harm. So if a single container is needed, the Text construct itself is 
the obvious container.

--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

Tim Bray wrote:
On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote:
That's an implementation issue that shouldn't affect the format.

Without any comment on the issue Julian was addressing, the above is 
outrageous.  Implementation issues are extremely material in discussion 
of the format.  Perhaps more material than anything else. -Tim
OK, I'll try to rephrase: changing the protocol format because one 
implementor says that this makes it easier to implement IMHO is a bad 
idea. Of course things look differently if this issue affects more 
platforms/parsers/toolkits.

So yes, more information is needed.
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Tim Bray]

On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote:
That's an implementation issue that shouldn't affect the format.
Without any comment on the issue Julian was addressing, the above is 
outrageous.  Implementation issues are extremely material in discussion 
of the format.  Perhaps more material than anything else. -Tim

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

Eric Scheid wrote:
On 31/1/05 4:43 AM, "Julian Reschke" <[EMAIL PROTECTED]> wrote:

"The content SHOULD be XHTML text and markup that could validly appear
directly within an xhtml:div element."
...so making it explicit in the on-the-wire format seems to be
completely useless.

what's missing though is guidance that the "XHTML text and markup" needs to
be in the xhtml namespace, and not just plonked in there by a crude
template-style publisher.
that is, it needs to be clear from the spec that this is wrong:
Here is a bold statement
...at least it's not what the producer probably intends.
Given the mass of content which is published via crude string concatenation
template driven CMS products, this is something we need to address. As it is
at the moment, a naïve reading of the spec suggests that the above atom XML
is valid because the  element *does* contain "XHTML text and markup
that could validly appear directly within an xhtml:div element".
By the way, are we assuming that the reader is meant to assume that the
namespace prefix "xhtml" has been bound to the xhtml namespace?
These are good points, so this should be clarified (independently of 
whether we require div or not).

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

Graham wrote:
On 30 Jan 2005, at 5:24 pm, Sam Ruby wrote:
I've reopened it minus the namespace restriction.  I realize that 
Henri is violently opposed to it, but his objection seem to reduce 
down to "cruft", and he seems to be in the minority.  I see there to 
be a good chance that rough consensus can be found on this pace.

I'm in favor of it. My current parser doesn't let me pull out "all 
childen of element x" in one go, so I have to step through in a really 
hacky way. With this I can just grab the div.
That's an implementation issue that shouldn't affect the format.
Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Re: PaceXhtmlNamespaceDiv posted

[Eric Scheid]

On 31/1/05 4:43 AM, "Julian Reschke" <[EMAIL PROTECTED]> wrote:

> "The content SHOULD be XHTML text and markup that could validly appear
> directly within an xhtml:div element."
> 
> ...so making it explicit in the on-the-wire format seems to be
> completely useless.

what's missing though is guidance that the "XHTML text and markup" needs to
be in the xhtml namespace, and not just plonked in there by a crude
template-style publisher.

that is, it needs to be clear from the spec that this is wrong:

Here is a bold statement

Given the mass of content which is published via crude string concatenation
template driven CMS products, this is something we need to address. As it is
at the moment, a naïve reading of the spec suggests that the above atom XML
is valid because the  element *does* contain "XHTML text and markup
that could validly appear directly within an xhtml:div element".

By the way, are we assuming that the reader is meant to assume that the
namespace prefix "xhtml" has been bound to the xhtml namespace?

e.

Re: PaceXhtmlNamespaceDiv posted

[Graham]

On 30 Jan 2005, at 5:24 pm, Sam Ruby wrote:
I've reopened it minus the namespace restriction.  I realize that 
Henri is violently opposed to it, but his objection seem to reduce 
down to "cruft", and he seems to be in the minority.  I see there to 
be a good chance that rough consensus can be found on this pace.
I'm in favor of it. My current parser doesn't let me pull out "all 
childen of element x" in one go, so I have to step through in a really 
hacky way. With this I can just grab the div.

+1
Graham

smime.p7s
Description: S/MIME cryptographic signature

Re: PaceXhtmlNamespaceDiv posted

[Asbjørn Ulsberg]

On Sun, 30 Jan 2005 18:43:18 +0100, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

For the record, I'm opposed to it, too.
Same here.
The spec is already saying this:
"The content SHOULD be XHTML text and markup that could validly appear  
directly within an xhtml:div element."

...so making it explicit in the on-the-wire format seems to be  
completely useless.
Indeed.
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: PaceXhtmlNamespaceDiv posted

[Julian Reschke]

Sam Ruby wrote:
...
I've reopened it minus the namespace restriction.  I realize that Henri 
is violently opposed to it, but his objection seem to reduce down to 
"cruft", and he seems to be in the minority.  I see there to be a good 
chance that rough consensus can be found on this pace.
...
For the record, I'm opposed to it, too. The spec is already saying this:
"The content SHOULD be XHTML text and markup that could validly appear 
directly within an xhtml:div element."

...so making it explicit in the on-the-wire format seems to be 
completely useless.

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760