On 1/2/05 5:31 AM, Antone Roundy [EMAIL PROTECTED] wrote:
Another option would be to allow one content with inline content, and
alternative content by reference, eg. (not being careful about getting
language tags correct):
+1
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.
The
On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio [EMAIL PROTECTED] wrote:
atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name
Well yes, and there's always:
atom
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
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,
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 different
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 down.
Nearly forgot -
+1 to including some kind of explanatory note on comparisons, Martin's
version looks better than the current text
--
http://dannyayers.com
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
convert an
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 (the
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 with the
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 that to be
* 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 you think
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
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:
atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name
Well yes, and there's always:
atom
The title of this feed is The Stuff and the
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
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
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
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
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
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
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
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 id URIs should be treated as URIs according to
webarch etc - it should be possible to dereference them, assuming
that's supported by the scheme.
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
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 version. [...]
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
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*
In
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
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
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
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 the
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.
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
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
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
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
Having produced my own Atom feed has made me a supporter of this Pace;
without getting too deep into it link rel=self feels quite sensible,
while link rel=icon feels stupid.
However, this Pace needed work; first of all, it was based on link
constructs, which no longer exist. So I revised it.
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.
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 link rel=self feels quite sensible,
while link rel=icon feels stupid.
+1
However, this Pace needed work; first of all, it was based on
38 matches
Mail list logo
