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: type=HTML

At 23:36 05/02/08, Julian Reschke wrote: >Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) I'd be very much in favor of that. The first step is to order the sections so that XHTML comes first. I h

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: type=HTML

Julian Reschke wrote: Sam Ruby wrote: Julian Reschke wrote: () The spec currently says: "If the value of "type" is "HTML", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable

Re: PaceDatesXSD

/ Graham <[EMAIL PROTECTED]> was heard to say: | -1 on the regex. It's completely | unreadable and hides whatever | additional constraints it adds. Write | those down in English please. Well, how about English and the regex? I'm worrying about interoperability here. There's considerable pressure t

Re: type=HTML

Sam Ruby wrote: Julian Reschke wrote: () The spec currently says: "If the value of "type" is "HTML", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling by softw

Re: PaceDatesXSD

-1 on the regex. It's completely unreadable and hides whatever additional constraints it adds. Write those down in English please. Graham

Re: PaceArchiveDocument

On 8 Feb 2005, at 12:14 am, Eric Scheid wrote: PaceArchiveDocument -1 this looks like a backdoor to feeds in feeds. -1, agreed. Graham

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

Well, I ain't gonna argue the point, but I'm going to stick by the assertion that feeder/head is ugly. Any use of this stuff I plan to make can live equally well with either approach. - James M Snell Walter Underwood wrote: --On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman <[EMAIL PR

RE: PaceHeadless

--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman <[EMAIL PROTECTED]> wrote: Linking to the feed is not an acceptable solution. It must be possible to embed feed metadata in an entry in a feed and in an Entry document. +1 The feed document *must* be standalone. Everything required to

Re: type=HTML

Sam Ruby wrote: Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Depending on the target environment, stripping the elements in XHTML may also be appropriate. I would strip both unless the phon

Re: PaceProfile

Antone Roundy wrote: On Tuesday, February 8, 2005, at 05:47 AM, Bill de hÓra wrote: [You mean we have to decide?!?. Now!?!] +1 on the concept. I've seen enough cases in the last week to suggest it's useful. -1 on "@profile" - use an @rel to hold the content instead. I'm not sure whether atom:fe

Re: PaceProfile

On Tuesday, February 8, 2005, at 05:47 AM, Bill de hÓra wrote: Robert Sayre wrote: Bill de hÓra wrote: The problem is that switching on the content of an element/attribute is Atom's get out of jail card wrt extensibility. It is the default Atom extensibility model, as it's the only game we have

Re: type=HTML

Julian Reschke wrote: () The spec currently says: "If the value of "type" is "HTML", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling by software that knows H

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

type=HTML

() The spec currently says: "If the value of "type" is "HTML", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling by software that knows HTML. The HTML markup mus

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

James M Snell wrote: > My preference would be a link based alternative. > > ... > > ... > > > I'm tired of arguing this one, so, I'm just going to say this one more time and leave it at that. Linking to the feed is not an acceptable solution. It must be possible to

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

Thanks Danny, that was a good summary. +1 for the title from me too. But I think the deadline for new paces has already passed. >:-> Henry On 8 Feb 2005, at 13:42, Danny Ayers wrote: On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra <[EMAIL PROTECTED]> wrote: Henry Story wrote: If you just want to

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

Danny Ayers wrote: On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra <[EMAIL PROTECTED]> wrote: Henry Story wrote: If you just want to stick to syntax, then please leave the pace as it is. Don't try to impose a model through syntax and then argue that people can't argue about the model that you are

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

Robert Sayre wrote: Bill de hÓra wrote: The problem is that switching on the content of an element/attribute is Atom's get out of jail card wrt extensibility. It is the default Atom extensibility model, as it's the only game we have to play that doesn't involve screwing about with the meaning of

Re: PaceLangSpecific

On Feb 8, 2005, at 10:43, David Powell wrote: text/plain can have a Content-Language header though - is that compatible with xml:lang? For practical purposes, yes. In theory, the semantics are different. xml:lang specifies the language of the content but Content-Language describes the language of

Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready

On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > Henry Story wrote: > > If you just want to stick to syntax, then please leave the pace > > as it is. Don't try to impose a model through syntax and then > > argue that people can't argue about the model that you are >

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

Henry Story wrote: If you just want to stick to syntax, then please leave the pace as it is. Don't try to impose a model through syntax and then argue that people can't argue about the model that you are surreptitiously trying to introduce. Henry, I have no idea what you are talking about. cheers B

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

On 8 Feb 2005, at 01:49, Roy T. Fielding wrote: On Feb 7, 2005, at 5:15 AM, Henry Story wrote: This is true only if you have the [Equivalence ID] interpretation of the id relation. (Ie you think of id as equivId.) Yes, and to make myself perfectly clear, that means functional ID, as you call it, wo

Re: PaceLangSpecific

Tuesday, February 8, 2005, 12:44:26 AM, you wrote: >> PaceLangSpecific > +1, but also needed for atom:generator > hmmm ... if we have xml:lang on , we are going to also need > @hreflang for , because while some types of referenced > content can have the language attached, at type="text/plain"