Re: Revised PaceIconAndImage, added PaceMultipleImages

On 2/2/05 5:49 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > Having produced my own Atom feed has made me a supporter of this Pace; > without getting too deep into it while However, this Pace needed work; first of all, it was based on link > constructs, which no longer exist. So I revised it. I

Re: URI canonicalization

On 2/2/05 11:52 AM, "Roy T. Fielding" <[EMAIL PROTECTED]> wrote: > any two > URIs that are different identifiers will never compare as > "equivalent", regardless of the comparison algorithm used. what about false negatives though? e.

PaceLinkEnclosure needs help

This Pace is a mess. I *think* its real purpose in life to suggest changing to . As it stands, it's highly likely to get drop-kicked by the chairs for being uncooked. If someone really wants this change, the Pace needs revision right now. -Tim

Revised PaceIconAndImage, added PaceMultipleImages

Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it However, this Pace needed work; first of all, it was based on link constructs, which no longer exist. So I revised it. Second, along with turning Icon and Image from into their own elemen

s/PaceFeedState/PaceFormatSecurity/ bleah

Sorry, typo. I repeat: there was lots of discussion, good input, and what smelled like convergence. Someone needs to update PaceFormatSecurity. -Tim

PaceFeedState to be updated?

There was a huge amount of discussion around PaceFeedState, with input from our AD, and what smelled like converging language on the list. Is someone going to update the Pace to take that into account? -Tim

Re: URI canonicalization

On 2 Feb 2005, at 2:34 am, Roy T. Fielding wrote: On Feb 1, 2005, at 5:12 PM, Graham wrote: On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: There is no need to explain what "different ids" means -- any two URIs that are different identifiers will never compare as "equivalent", regardless of the

Re: URI canonicalization

On Feb 1, 2005, at 5:12 PM, Graham wrote: On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: There is no need to explain what "different ids" means -- any two URIs that are different identifiers will never compare as "equivalent", regardless of the comparison algorithm used. Pardon? If I use case s

Re: URI canonicalization

On Jan 31, 2005, at 11:56 PM, Martin Duerst wrote: At 14:27 05/02/01, Roy T. Fielding wrote: >That would be a falsehood. Identifiers are not subject to >"simplification" -- they are either equivalent or not. We can >add all of the implementation requirements we like to prevent >software from dete

Trial format-05 atom feed

Just to see if it uncovered any problems, I twiddled the ongoing software to generate a format-05 atom feed. It didn't uncover any problems that I could see. Norm's RNC schema was very valuable in debugging, not that there were many bugs. Check it out at http://www.tbray.org/ongoing/ongoing.

Re: URI canonicalization

On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: There is no need to explain what "different ids" means -- any two URIs that are different identifiers will never compare as "equivalent", regardless of the comparison algorithm used. Pardon? If I use case sensitive ids (eg base64 style "http://www

Re: URI canonicalization

On Feb 1, 2005, at 4:28 PM, Roy T. Fielding wrote: Anyone who subscribes to aggregations (for example, I subscribe to the planetsun.org aggregated feed), is used to seeing the same entry over and over and over again. This problem is only going to get worse. With Atom's ID semantics and compuls

Re: URI canonicalization

On Feb 1, 2005, at 3:03 PM, Graham wrote: Aren't we approaching this problem from the wrong end? The id spec should be instructions for publishers saying "Any two versions of the same entry must use the same id, which requires that all characters are the same. Any two different entries must have

Re: Format spec vs Protocol spec

Robert Sayre wrote: Tim Bray wrote: On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). I suggest this can and should be removed. Agree. Fo

Re: URI canonicalization

On Feb 1, 2005, at 7:46 AM, Tim Bray wrote: On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id "http://tbray.org/uid/1000"; as the same entry, even when I received th

Re: URI canonicalization

On Feb 1, 2005, at 4:48 AM, Sam Ruby wrote: Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but no

Re: Format spec vs Protocol spec

Tim Bray wrote: On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). I suggest this can and should be removed. Agree. Robert Sayre

Re: Format spec vs Protocol spec

On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). I suggest this can and should be removed. --Tim

Re: URI canonicalization

On 2/2/05 10:03 AM, "Graham" <[EMAIL PROTECTED]> wrote: > Aren't we approaching this problem from the wrong end? The id spec > should be instructions for publishers saying "Any two versions of the > same entry must use the same id, which requires that all characters are > the same. Any two differ

Re: URI canonicalization

On 1 Feb 2005, at 10:33 pm, Antone Roundy wrote: Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. The values of two Identity constructs are considered to be the same if a case-sensitive character-by-character compa

Re: Feed State [was: Work Queue Rotation #16]

Tuesday, February 1, 2005, 5:18:44 AM, you wrote: > P.S. Feed Document may be somewhat misleading, because it's easy to > confuse it with Feed (which has connotations of the information > channel). I think "Feed Snapshot Document" or the like was once > proposed, but it was shot down. *shrug*

Entry order

Is the order of entries within a feed supposed to be significant? I can't see anything in the spec. I think we should say something - I'm guessing that it is not significant, and any ordering should be done using atom:updated or atom:published. It looks like this might have got lost accidently w

Re: URI canonicalization

On Monday, January 31, 2005, at 10:57 PM, Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but nob

Re: Questions about -04

Sorry, this was way back, but caught my eye again. At 11:39 05/01/27, Sam Ruby wrote: > >Martin Duerst wrote: >> At 01:51 05/01/26, Asbj
n Ulsberg wrote: >> > >> >On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby <[EMAIL PROTECTED]> >> >wrote: >> > >> >>> 2. Why MUST a feed point to an alternate v

Format spec vs Protocol spec

Hi, (I raised this when reviewing draft 05 already, but I think this topic deserves it's own thread) Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). As far as I understand the IETF pub

Re: Dereferencing Identity Constructs

I'm a little confused over what's being proposed or counterproposed here - I thought consensus last year was to break the Web Whatever, I do think URIs should be treated as URIs according to webarch etc - it should be possible to dereference them, assuming that's supported by the scheme. Th

Re: Principled Reasoning. was: PaceAggregationDocument posted

On Tuesday, February 1, 2005, at 06:08 AM, Henry Story wrote: ... Without taking the trouble to purchase and read the book you pointed to, here is my reasoning: Antone Roundy wrote: My preferences: +1: Current draft or PaceAggregationDocument (with or without atom:feed/atom:head and with or wit

Re: Comments on format-05

On Feb 1, 2005, at 10:17 AM, Robert Sayre wrote: We dropped multiple content elements months ago, with good reason. Two of the more serious concerns were accessbility and the fact that nobody uses them in Atom 0.3. As I understand it, the only reason they were there originally was for uploading

Re: URI canonicalization

Tim Bray wrote: On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id "http://tbray.org/uid/1000"; as the same entry, even when I received the first one from tbray.org a

Re: Comments on format-05

On Feb 1, 2005, at 10:17 AM, Graham wrote: There's an awful lot more to an aggregator than the 3 lines that pull stuff out of XML. My problem is that users want to see the content in their preferred language, which means I have to provide some mechanism to choose, which may end up being the most

Re: URI canonicalization

Henry Story wrote: On 1 Feb 2005, at 13:48, Sam Ruby wrote: Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent ide

Re: Comments on format-05

There's an awful lot more to an aggregator than the 3 lines that pull stuff out of XML. My problem is that users want to see the content in their preferred language, which means I have to provide some mechanism to choose, which may end up being the most complex part of a simple app. Additionall

Re: Comments on format-05

Mark Nottingham wrote: Using XPath as a yardstick, what's so complex about this? /atom:feed/atom:entry[1]/atom:[EMAIL PROTECTED]'HTML'|@type='TEXT'][0] I'm not even sure how I'd approach choosing between HTML and text in the current approach, where one is in atom:content and the other is referred

Re: Comments on format-05

Using XPath as a yardstick, what's so complex about this? /atom:feed/atom:entry[1]/atom:[EMAIL PROTECTED]'HTML'|@type='TEXT'][0] I'm not even sure how I'd approach choosing between HTML and text in the current approach, where one is in atom:content and the other is referred to by atom:link; I'd n

Re: Principled Reasoning. was: PaceAggregationDocument posted

On 1 Feb 2005, at 1:08 pm, Henry Story wrote: What is really needed here is some principled reasoning [1]. Otherwise we will be left clambering in the dark caverns of our individual prejudices. I suggest that when people make statements in favor or against something, principled reasons be given.

Re: Dereferencing Identity Constructs

Ahhh! Here I make the mistake again. The id relation, relating an Entry and a Identity Construct is functional, not inverse functional. Hence an Entry can only have one id relation to a URI of type identity construct. But there is a way out of this: if an entry has a number of id relations, the

Re: Comments on format-05

On 31 Jan 2005, at 7:02 pm, Mark Nottingham wrote: If the concern about multiple content is solely that it will result in more bandwidth use, I think it's misplaced; people who are concerned about bandwidth won't publish multiple representations inline; forcing them not to by legislation is misg

Re: URI canonicalization

Duh. Sorry. It is a functional property. I explained why myself at length here: All the rest can arguably be thought to be overspecification. Henry Story On 1 Feb 2005, at 17:06, Henry Story wrote: Yes, the id is an inverse functional pr

Re: URI canonicalization

On 1 Feb 2005, at 16:46, Tim Bray wrote: On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id "http://tbray.org/uid/1000"; as the same entry, even when I received the

Re: URI canonicalization

On 1 Feb 2005, at 13:48, Sam Ruby wrote: Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but nobo

Re: URI canonicalization

On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id "http://tbray.org/uid/1000"; as the same entry, even when I received the first one from tbray.org and the second fr

Re: Posted PaceTextRules

On Feb 1, 2005, at 11:08, Martin Duerst wrote: +1 with the minor nit that lone line breaks should be considered spaces--not disregarded. Thus: Software displaying this text SHOULD remove white-space at the beginning and end; and treat sequences of one or more XML white-space characters as a sing

Re: Posted PaceTextRules

On Feb 1, 2005, at 1:09 AM, Martin Duerst wrote: >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different >> opinion on this matter... > >Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm amazed that the W3C allowed that to be published. -Tim Would you mind e

Re: atom:host [was: Comments on format-05]

On Tue, 1 Feb 2005 10:58:52 +0100, Danny Ayers <[EMAIL PROTECTED]> wrote: > On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio <[EMAIL PROTECTED]> wrote: > > > Anonymous (from IP: aaa.bbb.ccc.) > > Well yes, and there's always: > > > The title of this feed is "The Stuff" and the first entry

Re: URI canonicalization

On 1 Feb 2005, at 5:27 am, Roy T. Fielding wrote: Identifiers are not subject to "simplification" -- they are either equivalent or not. We can add all of the implementation requirements we like to prevent software from detecting false negatives, but that doesn't change the fact that equivalent ide

Principled Reasoning. was: PaceAggregationDocument posted

What is really needed here is some principled reasoning [1]. Otherwise we will be left clambering in the dark caverns of our individual prejudices. I suggest that when people make statements in favor or against something, principled reasons be given. It should be possible then to discuss the va

Re: Posted PaceTextRules

* Martin Duerst wrote: > >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different > >> opinion on this matter... > > > >Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm amazed > >that the W3C allowed that to be published. -Tim > >Would you mind explaining why

Re: URI canonicalization

Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but nobody cares because AT WORST the result is a

Re: Posted PaceTextRules

At 00:38 05/02/01, Tim Bray wrote: > > >On Jan 31, 2005, at 5:37 AM, Bjoern Hoehrmann wrote: >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different >> opinion on this matter... > >Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm amazed that the W3C allowed th

Re: Posted PaceTextRules

At 17:09 05/01/31, Henri Sivonen wrote: > >On Jan 31, 2005, at 03:00, Graham wrote: > >> "Software displaying this text SHOULD remove white-space at the beginning and end; collapse white-space between words; and disregard line break, tab and other formatting characters." in 3.1.1 (TEXT). > >+1 wi

Re: IRIs (was: Re: Work Queue Rotation #16)

At 08:25 05/02/01, DJWS wrote: > >At 22:25 31/01/2005, Graham wrote: >>I don't know much about IRIs. Is it possible to express them as URIs? > >As far as I understand, and this is my problem : I cannot have a formal response on the following. >- there are various way to support a non ASCII IRI (th

Re: URI canonicalization

At 14:27 05/02/01, Roy T. Fielding wrote: > >On Jan 31, 2005, at 7:10 PM, Martin Duerst wrote: >> 5) Add a note saying something like "Comparison functions >>provided by many URI classes/implementations make additional >>assumptions about equality that are not true for Identity >>Constr

Re: IRIs

Clarifying some details based on my write-manytimes understanding of IRIs (RFC 3987). At 07:15 05/02/01, Robert Sayre wrote: > >Graham wrote: > >> I don't know much about IRIs. Is it possible to express them as URIs? > > >My read-the-draft-once understanding is that it is always possible to conver

Re: URI canonicalization

Nearly forgot - +1 to including some kind of explanatory note on comparisons, Martin's version looks better than the current text -- http://dannyayers.com

Re: Feed State [was: Work Queue Rotation #16]

On 1/2/05 4:18 PM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > P.S. Feed Document may be somewhat misleading, because it's easy to > confuse it with Feed (which has connotations of the information > channel). I think "Feed Snapshot Document" or the like was once > proposed, but it was shot dow

Re: URI canonicalization

On Tue, 01 Feb 2005 10:07:52 +, Bill de hÓra <[EMAIL PROTECTED]> wrote: > Otherwise, this thread sounds like resources and representations all > over with the caveat that entry representations are being sourced from > multiple origin servers. It was suggested ages ago that the use of a diffe

Re: URI canonicalization

Roy T. Fielding wrote: Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id "http://tbray.org/uid/1000"; as the same entry, even when I received the first one from tbray.org and the second from mymonkeysbutt.net? Oh yeah,

Re: URI canonicalization

Graham wrote: 4) Add a sentence saying something like "Feeds or Entries are identical if their IDs compare identical.". Seems obvious, but isn't stated anywhere. No. Feeds/entries with the same id are different versions or instances of a common ancestor. They are not "the same". +1. It is r

Re: atom:host [was: Comments on format-05]

On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio <[EMAIL PROTECTED]> wrote: > Anonymous (from IP: aaa.bbb.ccc.) Well yes, and there's always: The title of this feed is "The Stuff" and the first entry it contains is titled "Hello World" from 1st February, and that has the content "... Wha

Re: Work Queue Rotation #16

On Mon, 31 Jan 2005 11:45:25 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > Atom Public Issues List: > http://www.intertwingly.net/wiki/pie/AtomPubIssuesList Regarding PaceExtensionConstruct, PaceAttributesNamespace and Henry's RDF-related proposals, these got Catch-22'd by the process a little.

Re: Comments on format-05

On 1/2/05 5:31 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > Another option would be to allow one with inline content, and > alternative content by reference, eg. (not being careful about getting > language tags correct): +1

Re: Comments on format-05

On 1/2/05 6:02 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > If the concern about multiple content is solely that it will result in > more bandwidth use, I think it's misplaced; people who are concerned > about bandwidth won't publish multiple representations inline; forcing > them not to by