Re: PaceXhtmlNamespaceDiv
(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$BS(Bst in (Bhttp://www.imc.org/atom-syntax/mail-archive/msg13531.html: (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 xhtml:div (B element as the content of the atom:content 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 (Bxhtml: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: PaceXhtmlNamespaceDiv
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 xhtml:div/ 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
Henri Sivonen wrote: On Feb 9, 2005, at 15:28, Sam Ruby wrote: Here's the key question. Consider the following XML fragment: summary type='XHTML'div xmlns='http://www.w3.org/1999/xhtml'Hey, this is my space, if I want to run a picture of a chair I can. And its a emnice/em chair./div/summary 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
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
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
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 http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
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
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 http://www.imc.org/atom-syntax/mail-archive/msg12697.html: 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 http://www.imc.org/atom-syntax/mail-archive/msg13531.html: Note: It is important to make sure that correct namespace declarations for XHTML are present. One way to do this is by using an xhtml:div element as the content of the atom:content 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
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 http://www.imc.org/atom-syntax/mail-archive/msg13531.html: Note: It is important to make sure that correct namespace declarations for XHTML are present. One way to do this is by using an xhtml:div element as the content of the atom:content 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 div 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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
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
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
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
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: pWhat a nice day!/p My XHTML container element is p. 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): feed entry summary pWhat a nice day!/p /summary /entry /feed Depending on the how the question is phrased, one could take the position that feed, entry, and summary 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: feed entry summary div pWhat a nice day!/p /div /summary /entry /feed 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
Re: PaceXhtmlNamespaceDiv
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: atom:summary xmlns:atom=... xmlns=... 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 xhtml:div element between the atom:summary 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 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: pWhat a nice day!/p My XHTML container element is p. 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): feed entry summary pWhat a nice day!/p /summary /entry /feed Yep. Depending on the how the question is phrased, one could take the position that feed, entry, and summary 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: feed entry summary div pWhat a nice day!/p /div /summary /entry /feed 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,
Re: PaceXhtmlNamespaceDiv
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 divs. I can anticipate that happening either way. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
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? a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us' ... a:entry ... a:content type='XHTML'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying a href='http://dvforge.com/themousebt.shtml'The Mouse BT/a from some outfit ... OR (even less impact on string concatenators): feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xml:lang='en-us' ... entry ... a:content type='XHTML' xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' xmlns='http://www.w3.org/1999/xhtml'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying a href='http://dvforge.com/themousebt.shtml'The Mouse BT/a from some outfit ... -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
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
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
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 div 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 div 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
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? lt;divgt; ... lt;/divgt; Yes. Suggesting this seems petty. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
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 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
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 xhtml:div 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 div 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 xhtml:div element as the content of the atom:content 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
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 xhtml:div element as the content of the atom:content 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
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
Re: PaceXhtmlNamespaceDiv
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
Re: PaceXhtmlNamespaceDiv
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
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 content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is xhtml:bbold/xhtml:b/content This is against the Pace. Are you really supporting the pace? OR content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content This is against the Pace, too. OR contentdiv xmlns=... /This is bbold/b/content 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: contentThis is b xmlns=... bold/b/content IMO, that should be allowed. Atom has no business in restricting the syntactic sugar provided by Namespaces in XML. OR contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content IMO, this on should be allowed on the same grounds. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv
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 content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is xhtml:bbold/xhtml:b/content OR content xmlns:xhtml=... /This is xhtml:bbold/xhtml:b/content OR contentdiv xmlns=... /This is bbold/b/content Here's what I think is just plain ugly and shouldn't be allowed: contentThis is b xmlns=... bold/b/content OR contentThis is xhtml:b xmlns:xhtml=... bold/xhtml:b/content
Re: PaceXhtmlNamespaceDiv
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 http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
Yes, sorry I wasn't clear. Not *only* on ancestor elements. any of the following cases should be allowed. feed entry content xhtml:div xmlns:xhtml=... / /content /entry /feed feed entry content xmlns:xhtml=... xhtml:div / /content /entry /feed feed entry xmlns:xhtml=... content xhtml:div / /content /entry /feed feed xmlns:xhtml=... entry content xhtml:div / /content /entry /feed - 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
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 content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content 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
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
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 content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content 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 http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
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 div 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
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 div 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 http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
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 content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content I do not follow this example. The point is that content / 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 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 div 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 divs. 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
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
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
I'm +1 when wearing my aggregator hat, and indifferent from a publishing perspective. -- Roger Benningfield JournURL
Re: PaceXhtmlNamespaceDiv
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 div nesting - call it gut feeling (it's an escaping mechanism after all). cheers Bill
Re: PaceXhtmlNamespaceDiv
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
PaceXhtmlNamespaceDiv +1
Re: PaceXhtmlNamespaceDiv
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? a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us' ... a:entry ... a:content type='XHTML'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying a href='http://dvforge.com/themousebt.shtml'The Mouse BT/a from some outfit ... OR a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us' ... a:entry ... a:content type='XHTML'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying h:a href='http://dvforge.com/themousebt.shtml'The Mouse BT/h:a from some outfit ... OR feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us' ... entry ... content type='XHTML'I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying h:a href='http://dvforge.com/themousebt.shtml'The Mouse BT/h:a from some outfit ... -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv posted
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
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv posted
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
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
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: content type=XHTMLHere is a bbold statement/b/content 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 content 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 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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv posted
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: content type=XHTMLHere is a bbold statement/b/content ...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 content 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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv posted
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
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv posted
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
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
On Jan 29, 2005, at 00:39, Sam Ruby wrote: Henri Sivonen wrote: On Jan 28, 2005, at 20:21, Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace correctness in my RSS feed. If the current spec language stands, I will be able to trivially add Atom output with type='XHTML' by doing a DOM to DOM copy (without div cruft) and letting the serialization phase sort out the namespace declarations for me. If this pace was accepted, I'd have to break the namespace abstraction and fiddle with the namespace declaration details to meet additional requirements that are unnecessary as per Namespaces in XML. Are you saying that you can do a DOM to DOM copy to place a series of elements inside the following: atom:feed/atom:entry/atom:content But you would find it extraordinarily difficult to place the exact same series of elements inside the following: atom:feed/atom:entry/atom:content/xhtml:div If so, I would find such an assertion to be hard to accept. No, of course those two are equally easy. The latter is just crufty. My point was that having the namespace declarations appear in a particular choice of syntactic sugar would hinder the use of an automatic namespace declaration manager. If element names are prefixed, string concatenation is not an option anyway. Which is why it would be harmful to imply that a string concatenation implementation was ok. If element names are not prefixed (as is the case with the overwheming majority of existing HTML), adding a div is exactly what makes things safe for simple string concatenators. I don't see how it makes string concatenation easier that concatenating the contents of the Text construct otherwise. But since it doesn't work in all cases, it certainly should not be specced for. Speccing for tag soup concatenation would just encourage implementors to do tag soup concatenation. Wasn't the whole reason for the existence of type='XHTML' to provide something that is more sound from the XML point of view than entity-encoded HTML? And no, a div does not give any useful hint to the ViewSourceClan, because it is an anything goes element. I am sorry I brought up the subject of Text constructs. How about withdrawing both PaceTypeTextRedundant and PaceXhtmlNamespaceDiv and sticking to what draft-ietf-atompub-format-04 said? -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv posted
On Thu, 27 Jan 2005 13:30:40 -0700, Antone Roundy [EMAIL PROTECTED] wrote: As far as the question of CSS and/or elements/tags everywhere, I'd think that would be a matter for the security considerations section (protecting against the Raging Platypus, for example). Whatever restrictions we may pronounce, consumers will still have to include code to protect against abuses. And these issues apply equally to HTML as to XHTML. I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. +1, and the same goes for 'id', just leave it as an item for the security considerations. -joe -- Joe Gregoriohttp://bitworking.org
Re: PaceXhtmlNamespaceDiv posted
Antone Roundy wrote: On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote: On Jan 27, 2005, at 22:30, Antone Roundy wrote: I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. The namespace div places restrictions on where namespace declarations appear and, therefore, limits the legitimate use of serializers that take care of namespace declarations. -1 for the pace, still. Okay, this one's obviously dead. Let's just make sure we have examples that make how all these things work clear. I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. Consumers don't want full web pages (complete with html head and titles) as summaries, they want something that they can *insert* into a web page. Requiring a div element addresses a number of needs - it makes it easier to get the namespace right, and it succinctly provides a rather good hint as to what child elements are valid. On content, the situation is a bit different - the content need not be displayable, after all. I would be OK with either keeping the definition of type='XHTML' consistent (there are other types available, after all) or requiring a summary element to be present if the first child element of atom:content with type='XHTML' is not an xhtml:div. - Sam Ruby
Re: PaceXhtmlNamespaceDiv posted
Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. Consumers don't want full web pages (complete with html head and titles) as summaries, they want something that they can *insert* into a web page. Requiring a div element addresses a number of needs - it makes it easier to get the namespace right, and it succinctly provides a rather good hint as to what child elements are valid. That's what the spec already says, doesn't it? - http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1.p.6 ... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv posted
On 28 Jan 2005, at 6:21 pm, Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. Yes. and it succinctly provides a rather good hint as to what child elements are valid. Yes. I would be OK with either keeping the definition of type='XHTML' consistent (there are other types available, after all) Yes. or requiring a summary element to be present if the first child element of atom:content with type='XHTML' is not an xhtml:div. Ew. Graham
Re: PaceXhtmlNamespaceDiv posted
Julian Reschke wrote: Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. Consumers don't want full web pages (complete with html head and titles) as summaries, they want something that they can *insert* into a web page. Requiring a div element addresses a number of needs - it makes it easier to get the namespace right, and it succinctly provides a rather good hint as to what child elements are valid. That's what the spec already says, doesn't it? - http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1.p.6 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 posted
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. +1 -- Roger Benningfield
Re: PaceXhtmlNamespaceDiv posted
Henri Sivonen wrote: On Jan 28, 2005, at 20:21, Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace correctness in my RSS feed. If the current spec language stands, I will be able to trivially add Atom output with type='XHTML' by doing a DOM to DOM copy (without div cruft) and letting the serialization phase sort out the namespace declarations for me. If this pace was accepted, I'd have to break the namespace abstraction and fiddle with the namespace declaration details to meet additional requirements that are unnecessary as per Namespaces in XML. Are you saying that you can do a DOM to DOM copy to place a series of elements inside the following: atom:feed/atom:entry/atom:content But you would find it extraordinarily difficult to place the exact same series of elements inside the following: atom:feed/atom:entry/atom:content/xhtml:div If so, I would find such an assertion to be hard to accept. (Similar considerations apply to GenX if the user chooses to leave namespace declaration management to the serializer.) Consumers don't want full web pages (complete with html head and titles) as summaries, they want something that they can *insert* into a web page. Insertion is possible without a div as well if the insertion is implemented using proper XML tools and the target of the insertion is a real XHTML skeleton and not a tag soup skeleton and the resulting document is sent down the XML code path of Gecko, WebCore, Presto, etc. For Trident, the aggregator would have to serialize to HTML, which is pretty easy. On the other hand, a div does not make Atom safe for tag soup concatenators, because the element names may be prefixed. If element names are prefixed, string concatenation is not an option anyway. If element names are not prefixed (as is the case with the overwheming majority of existing HTML), adding a div is exactly what makes things safe for simple string concatenators. - Sam Ruby
Re: PaceXhtmlNamespaceDiv posted
On Jan 27, 2005, at 22:30, Antone Roundy wrote: I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. The namespace div places restrictions on where namespace declarations appear and, therefore, limits the legitimate use of serializers that take care of namespace declarations. -1 for the pace, still. -- Henri Sivonen [EMAIL PROTECTED] http://iki.fi/hsivonen/
Re: PaceXhtmlNamespaceDiv posted
On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote: On Jan 27, 2005, at 22:30, Antone Roundy wrote: I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. The namespace div places restrictions on where namespace declarations appear and, therefore, limits the legitimate use of serializers that take care of namespace declarations. -1 for the pace, still. Okay, this one's obviously dead. Let's just make sure we have examples that make how all these things work clear.
