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$B—S(Bst in (B: (B >> "Note: It is

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 unabiguou

Re: PaceXhtmlNamespaceDiv

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

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 k

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. [...] Anot

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 ba

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

Re: PaceXhtmlNamespaceDiv

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

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". Th

Re: PaceXhtmlNamespaceDiv

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 th

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

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

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

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 f

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 t

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 el

Re: PaceXhtmlNamespaceDiv

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 cor

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

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

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

Re: PaceXhtmlNamespaceDiv

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

Re: PaceXhtmlNamespaceDiv

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 res

Re: PaceXhtmlNamespaceDiv

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

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 > element as the content of the element and specifying > the XHTML namespace on that div element. Her

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)

Re: PaceXhtmlNamespaceDiv

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

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 Kest

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 declaratio

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

Re: PaceXhtmlNamespaceDiv

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 n

Re: PaceXhtmlNamespaceDiv

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

Re: PaceXhtmlNamespaceDiv

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 a

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

Re: PaceXhtmlNamespaceDiv

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 th

Re: PaceXhtmlNamespaceDiv

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

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 con

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

Re: PaceXhtmlNamespaceDiv

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

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

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

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? ... ... I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buyi

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 w

Re: PaceXhtmlNamespaceDiv

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

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

Re: PaceXhtmlNamespaceDiv

> PaceXhtmlNamespaceDiv +1

Re: PaceXhtmlNamespaceDiv

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

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 y

Re: PaceXhtmlNamespaceDiv

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

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 experimen

Re: PaceXhtmlNamespaceDiv

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

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 -- bytes GmbH -- http://www.greenbyte

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

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 an

Re: PaceXhtmlNamespaceDiv

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 co

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 element is top level container) for us to do: ...

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.

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

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 element is top level container) for us to do: ... ... I do not fol

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.

Re: PaceXhtmlNamespaceDiv

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 acce

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 element is top level container) for us to do: ... ... In my opinion, the XML contained

Re: PaceXhtmlNamespaceDiv

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,

Re: PaceXhtmlNamespaceDiv

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 ab

Re: PaceXhtmlNamespaceDiv

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

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

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

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 or before . Examples of what I'd think was acceptable: ... This is bold This is against the P

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

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

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

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

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 somethi

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

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

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 t

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

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 consensu

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 gui

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

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 expli

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 t

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 plac

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 t

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

Re: PaceXhtmlNamespaceDiv posted

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 la

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

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

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

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.

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 plac

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

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 wh

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 legit

Re: PaceXhtmlNamespaceDiv posted

On Thursday, January 27, 2005, at 12:32 PM, Antone Roundy wrote: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace. Would it be too picky to assert that this language doesn't allow whitespace before and

Re: PaceXhtmlNamespaceDiv posted

On Thursday, January 27, 2005, at 01:32 PM, Anne van Kesteren wrote: Antone Roundy wrote: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace. The xhtml:div MAY contain XHTML s/MAY/SHOULD/, surely? Yes, but

Re: PaceXhtmlNamespaceDiv posted

Antone Roundy wrote: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace. The xhtml:div MAY contain XHTML s/MAY/SHOULD/, surely? Yes, but getting the wording precise without being too verbose is a little tri

Re: PaceXhtmlNamespaceDiv posted

On Thursday, January 27, 2005, at 12:45 PM, Anne van Kesteren wrote: http://www.w3.org/1999/xhtml"; style="color:#03c;">This is XHTML content. Can't we forbid the STYLE attribute? Or define a subset of allowed elements/attribute? On this mandatory div, or everywhere? If we forbid it on this div,

Re: PaceXhtmlNamespaceDiv posted

On Thursday, January 27, 2005, at 12:58 PM, Tim Bray wrote: On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace. The xhtml:div MAY contain XHTML s/MAY/SHO

Re: PaceXhtmlNamespaceDiv posted

On Thursday, January 27, 2005, at 12:45 PM, Anne van Kesteren wrote: http://www.w3.org/1999/xhtml";>This is XHTML content. This DIV element != xhtml:div so this example would be invalid, right? Oops. Fixed it.

Re: PaceXhtmlNamespaceDiv posted

On Jan 27, 2005, at 11:32 AM, Antone Roundy wrote: If the value of "type" is "XHTML", the content of the Text construct MUST be a single xhtml:div element which MUST declare the XHTML namespace. The xhtml:div MAY contain XHTML s/MAY/SHOULD/, surely? text and markup that could validly appear dire

  1   2   >