* James Holderness [EMAIL PROTECTED] [2005-12-14 18:54]:
Alan Gutierrez wrote:
For commentsRSS, you could convert to:
link rel=replies type=application/rss+xml href={url} /
The one caveat is that the replies link rel has not yet been
registered in the IANA link registry.
Thank you
Alan Gutierrez wrote:
you're going to have to make do with application/rss+xml. It's about as
official a type as you can get for an RSS feed, but it's not registered
because it can't be registered.
Okay, I'm curious.
With no stake in the answer, mind you, why can it not be registered?
From
FWIW, real specification == internet draft / standards track rfc / etc
James Holderness wrote:
Alan Gutierrez wrote:
you're going to have to make do with application/rss+xml. It's
about as
official a type as you can get for an RSS feed, but it's not registered
because it can't be
For commentsRSS, you could convert to:
link rel=replies type=application/rss+xml href={url} /
The one caveat is that the replies link rel has not yet been
registered in the IANA link registry.
- James
Alan Gutierrez wrote:
I'm creating an XSLT transform to convert from RSS 2.0 to Atom 1.0
* James M Snell [EMAIL PROTECTED] [2005-12-14 12:57]:
For commentsRSS, you could convert to:
link rel=replies type=application/rss+xml href={url} /
The one caveat is that the replies link rel has not yet been
registered in the IANA link registry.
Thank you James.
IANA doesn't seem to
Alan Gutierrez wrote:
For commentsRSS, you could convert to:
link rel=replies type=application/rss+xml href={url} /
The one caveat is that the replies link rel has not yet been
registered in the IANA link registry.
Thank you James.
IANA doesn't seem to list application/rss+xml either.
James M Snell wrote:
FYI: Thanks to Robert Sayre for pointing it out, but when y'all get a
chance, take a look at the internals of the new Google Reader app
(http://reader.google.com). It's using AJAX and Atom 1.0 feeds to serve
up the data into the browser interface. The interface
On 10/11/05, Julian Reschke [EMAIL PROTECTED] wrote:
Hm. As far as I can tell, it doesn't process Atom content of type XHTML,
for instance (http://greenbytes.de/tech/webdav/webdav.atom).
There are definitely bugs with every feed format right now, but I
tried http://tantek.com/log/posts.atom
Yes, there actually appear to be quite a few problems with the service
right now. Hopefully they'll get those worked out. I'm also concerned
about their use of named linked relations. I understand that the feeds
they are using to drive their app are intended only for their app, but
it
Would dc:conformsTo work in this case?
Aleksander Slominski wrote:
James M Snell wrote:
Aleksander Slominski wrote:
it is interesting that atom reader (in this case it seems to
SharpReader) is actually rendering text content of
|content type=application/xml
EndpointReference
Aleksander Slominski wrote:
it is interesting that atom reader (in this case it seems to
SharpReader) is actually rendering text content of
|content type=application/xml
EndpointReference
xmlns=http://www.w3.org/2005/08/addressing;
A. Pagaltzis wrote:
Atom is not a weblog aggregation format.
It can be used in that capacity, and certainly is the finest
choice for that, but that is only one possible use case, and
applications using Atom should not be bent around it.
Putting the EndpointReference in the content is the
James M Snell wrote:
Aleksander Slominski wrote:
it is interesting that atom reader (in this case it seems to
SharpReader) is actually rendering text content of
|content type=application/xml
EndpointReference
xmlns=http://www.w3.org/2005/08/addressing;
FYI...
Example of an interesting non-blog use of Atom syndication:
http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/
- James
FYI: Thanks to Robert Sayre for pointing it out, but when y'all get a
chance, take a look at the internals of the new Google Reader app
(http://reader.google.com). It's using AJAX and Atom 1.0 feeds to serve
up the data into the browser interface. The interface itself leaves a
lot
James M Snell wrote:
FYI...
Example of an interesting non-blog use of Atom syndication:
http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/
it is interesting that atom reader (in this case it seems to
SharpReader) is actually rendering text content of
|content
* Aleksander Slominski [EMAIL PROTECTED] [2005-10-08 04:00]:
it is interesting that atom reader (in this case it seems to
SharpReader) is actually rendering text content of […] are atom
readers supposed to do that?
They’re certainly free to. Atom does not dictate what you do
with the bits
Bill de hÓra wrote:
[[[
line 7, column 141: service.post is not a valid link relationship
... eblog/blog_id=3 title=Bill de hÓra /
line 15, column 163: service.edit is not a valid link relationship (15
occurrences)
... id=1688 title=XML Virtual Machines /
line 157, column 33: Two
Here's the feedvalidator results for my journal served up as Atom1.0 as
per MT3.2's Atom1.0 template
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net%2Fjournal%2Fatom.xml
I also see it uses tag: uris as the atom:id value. I think I'll change
the template to use the http: URI
* Bill de hÓra [EMAIL PROTECTED] [2005-09-09 14:10]:
I also see it uses tag: uris as the atom:id value. I think I'll
change the template to use the http: URI generated by MT3.2 for
the individual entries instead of the tag: (what the rest of
the world calls permalinks).
Just make sure it
On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote:
Here's the feedvalidator results for my journal served up as
Atom1.0 as
per MT3.2's Atom1.0 template
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net%
2Fjournal%2Fatom.xml
I'm getting a 404 on that (or rather the
Tim Bray wrote:
On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote:
Here's the feedvalidator results for my journal served up as Atom1.0 as
per MT3.2's Atom1.0 template
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net%
2Fjournal%2Fatom.xml
I'm getting a 404 on that
Published yesterday on developerWorks.
http://www-128.ibm.com/developerworks/xml/library/x-atom10.html
Comments welcome.. I'll publish clarifications/corrections on my
developerWorks blog.
FYI: http://www.snellspace.com/wp/?p=196
IT Conversations Atom Podcasts. Just experimenting. I created these so
that I could play around with a personalized version of ipodder that I'm
updating to support Atom 1.0 podcasts.
- James
Tuesday, July 19, 2005, 12:44:51 AM, A. Pagaltzis wrote:
You misunderstood what I said. The point is that regardless of
how the base URI is determined (whether it is embedded in content
or otherwise), it *means* that the content it applies to was
actually found at the base URI. It’s not
* David Powell [EMAIL PROTECTED] [2005-07-19 08:25]:
Why does xml:base allow for relative base URIs and stacking
then? If xml:base can only describe the actual source URI of
the document, then these features don't make sense.
Indeed, they don’t.
The example in the xml:base spec [1] uses a
A. Pagaltzis wrote:
It makes me wonder whether the person who wrote the example was
unaware of the consequences of the same-document reference
specifications in the URI RFC. Surely, the xml:base WG must have
noticed this issue and discussed it?
I wonder how many people are aware of it. I
If anyone comes to a definitive conclusion on this,
would they post to the list, or a website please.
TIA
--
Regards,
Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 12:35]:
I don't find applying same-document reference behaviour to
fragments of an aggregate document non-sensical. If I XInclude
a piece of XHTML that has same-document references in it, I
still want them to be same-document references, and
* Graham [EMAIL PROTECTED] [2005-07-20 01:20]:
While I agree this interpretation is potentially correct, it
moves us pretty far away from the idea of a self-contained
document with a singular embedded base URI, which is all that
RFC2396 ever discusses.
That is pretty much what I said; yes.
Tim Bray wrote:
On Jul 17, 2005, at 8:16 AM, Sam Ruby wrote:
Upon further reading of 3986, I'm convinced that Tim's current feed
is correct.
I think so too, but I'm worried how XML-reader implementations will do
supporting all this base-URI stacking. If this kind of thing is going
xmlns='http://www.w3.org/2005/Atom'
xml:base='http://www.tbray.org/ongoing/ongoing.atom'
xml:lang='en-us'
titleongoing/title
link href='./' /
link rel='self' href='' /
...
entry xml:base='When/200x/2005/07/14/Atom-1.0'
If you want it to be perfect
link href='./' /
link rel='self' href='' /
...
entry xml:base='When/200x/2005/07/14/Atom-1.0'
If you want it to be perfect xml:base on the entry would be the
URI of the Atom Entry Document. And the html base URI should go
on the xhtml div element. Just like you get when
A. Pagaltzis wrote:
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 01:25]:
A. Pagaltzis wrote:
He is correct, Tim. The base URI means “the URL where this
document was found,” not “the prefix for any enclosed relative
links.” I don’t see how RFC3986 can be read any other way.
I am correct
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 03:15]:
That is my interpretation too, but only through the way the
base URI is used. I can't find any hint in that direction
otherwise. It would be nice if T. Berners-Lee, R. Fielding or
L. Masinter could confirm that. If it would have been
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers to a URI that is, aside
Sjoerd Visscher wrote:
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers to a
* Sjoerd Visscher wrote:
And that's why you can't use it as a reference to your site.
That depends a bit on same-document reference processing of Atom
processors. If the Atom processor assumes the link refers to some
web site and passes the absolute reference to some other user agent
there would
Sjoerd Visscher wrote:
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers to a
Sam Ruby wrote:
Upon further reading of 3986, I'm convinced that Tim's current feed is
correct.
Base URI defaults to the Retrieval URI. This gives rise to the common
use case of same-document references.
However, Base URI Embedded in Content. In XML documents, this takes the
form of
Bjoern Hoehrmann wrote:
* Sjoerd Visscher wrote:
And that's why you can't use it as a reference to your site.
That depends a bit on same-document reference processing of Atom
processors. If the Atom processor assumes the link refers to some
web site and passes the absolute reference to
On 17 Jul 2005, at 4:20 pm, Sjoerd Visscher wrote:
Where did you read that same-document references only apply when
there is no embedded base URI?
Scroll down to the algorithm in 5.2.2, and it backs up Tim and Sam,
in particular this:
if (R.path == ) then
technology, baby./generator
entry xml:base='http://www.tbray.org/ongoing/When/200x/2005/07/14/'
titleAtom 1.0/title
link href='Atom-1.0' /
idhttp://www.tbray.org/ongoing/When/200x/2005/07/14/Atom-1.0/id
published2005-07-14T13:00:00-08:00/published
updated2005-07-16T11:17:12-08:00/updated
to write. ;-)
- - -
While it clearly shouldn't be the default behavior, longer term (i.e.,
sometime well after basic Atom 1.0 support is more complete), how much
value do you think that there would be value in an option to attempt to
verify all potentially dereferencable URIs resolve
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
While it clearly shouldn't be the default behavior, longer term
(i.e., sometime well after basic Atom 1.0 support is more
complete), how much value do you think
='' /
link rel='self' href='ongoing.atom' /
...
entry xml:base='When/200x/2005/07/14/'
titleAtom 1.0/title
link href='Atom-1.0' /
On May 10, 2005, at 1:27 PM, Robert Sayre wrote:
If we choose a specific name, it *must* be in the RFC. Because the RFC
must be a hit for that search.
Marketing: Atom
Technical: Atom (RFC)
I was gonna suggest that too. I think RFC's are into the 4000-space
these days so if we end up as
Marketing: Atom
Technical: Atom (RFC)
+1
--
http://dannyayers.com
On 5/11/05, Danny Ayers [EMAIL PROTECTED] wrote:
Marketing: Atom
Technical: Atom (RFC)
+1
Hmm. I forgot one little detail. It might take like 4-6 months to get
an RFC number after IESG approval.
Robert Sayre
Marketing: Atom
I'm looking forward to an article by Mark Pilgrim about the
incompatible versions of Atom deceitfully marketed as one thing. :-)
(Which is why I said +1 to Atom 1.0.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Henri Sivonen wrote:
Marketing: Atom
I'm looking forward to an article by Mark Pilgrim about the incompatible
versions of Atom deceitfully marketed as one thing. :-)
(Which is why I said +1 to Atom 1.0.)
ARSS, short for Atom RSS. The marketing possibilities are endless.
cheers
Bill
* Bill de hra [EMAIL PROTECTED] [2005-05-11 17:05]:
ARSS, short for Atom RSS. The marketing possibilities are
endless.
How about Atom Syndication Standard?
I guess the Firefox crowd can then resurrect the non-Wifi looking
autodiscovery icon.
Regards,
--
Aristotle
On Wednesday, May 11, 2005, at 09:09 AM, A. Pagaltzis wrote:
* Bill de hÓra [EMAIL PROTECTED] [2005-05-11 17:05]:
ARSS, short for Atom RSS. The marketing possibilities are
endless.
How about Atom Syndication Standard?
So, ASS = Atom Syndication Standard. Or is it Atom Standard for
Syndication?
At 9:45 AM -0400 5/11/05, Robert Sayre wrote:
On 5/11/05, Danny Ayers [EMAIL PROTECTED] wrote:
Marketing: Atom
Technical: Atom (RFC)
+1
Hmm. I forgot one little detail. It might take like 4-6 months to get
an RFC number after IESG approval.
s/might/probably will/
--Paul Hoffman,
deployed that
it'll be with us for a while. Per WG consensus, an Atom doc has no
version stamp. So there'll be no actual spec-based reason to call our
product "Atom 1.0". But, we could just go ahead and do it anyhow.
Anyone have a better idea? --Tim
"Atom 1.0" was the term we (Dan
* Tim Bray [EMAIL PROTECTED] [2005-05-10 04:40]:
We definitely need some quick, snappy label to refer to that
version to distinguish it from Atom 0.3
there'll be no actual spec-based reason to call our product
Atom 1.0. But, we could just go ahead and do it anyhow.
+1 for Atom 1.0 since
On 10/5/05 7:27 PM, Graham [EMAIL PROTECTED] wrote:
Which sounds better?
Atom 1.0 released
Atom is finished
Atom is ready
e.
On May 10, 2005, at 05:29, Tim Bray wrote:
Atom 1.0
+1 for Atom 1.0 in order to distinguish from 0.3.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
At 9:09 PM -0700 5/9/05, Walter Underwood wrote:
Seriously, I don't mind Atom 1.0 as long as the next version is
Atom 2.0.
+12
--Paul Hoffman, Director
--Internet Mail Consortium
or SMTP or POP
or XML by their version numbers unless they have to. Including the
version number makes it sound like their are other versions that
matter, and for the moment, they're aren't.
Which sounds better?
Atom 1.0 released
Atom is finished
Graham
I think we should distinguish
--On Tuesday, May 10, 2005 09:12:09 AM -0700 Paul Hoffman [EMAIL PROTECTED] wrote:
At 9:09 PM -0700 5/9/05, Walter Underwood wrote:
Seriously, I don't mind Atom 1.0 as long as the next version is
Atom 2.0.
+12
I'd also be happy with just Atom and saying RFC Atom when
pressed for a version
On 5/10/05, Walter Underwood [EMAIL PROTECTED] wrote:
If we choose a specific name, it *must* be in the RFC. Because the RFC
must be a hit for that search.
Walter, that's a good point. How about:
Marketing: Atom
Technical: Atom (RFC)
?
Robert Sayre
On 10 May 2005, at 9:27 pm, Robert Sayre wrote:
Walter, that's a good point. How about:
Marketing: Atom
Technical: Atom (RFC)
Around Dave Winer: RFC
The only real problem with dropping the version number is making it
clear there've been major changes since 0.3.
Graham
Walter Underwood wrote:
I'd also be happy with just Atom and saying RFC Atom when
pressed for a version.
+1
- Sam Ruby
and it's now a mess for
tools developers.
+1 to the suggestion of Atom 1.0
--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***
Walter Underwood wrote:
If we choose a specific name, it *must* be in the RFC. Because the RFC
must be a hit for that search.
We can Google-bomb that string I guess. (Atom 1.0.)
--
Anne van Kesteren
http://annevankesteren.nl/
stamp. So there'll be no actual spec-based reason to call our
product Atom 1.0. But, we could just go ahead and do it anyhow.
Anyone have a better idea? --Tim
doc has no
version stamp. So there'll be no actual spec-based reason to call our
product Atom 1.0. But, we could just go ahead and do it anyhow.
Anyone have a better idea? --Tim
First time commenting on the list, be gentle. :-)
+1 on Tim's suggestion to use Atom 1.0. Atom 0.3 more or less
has no
version stamp. So there'll be no actual spec-based reason to call our
product Atom 1.0. But, we could just go ahead and do it anyhow.
Anyone have a better idea? --Tim
non:serious response=joke
Let's see: Atom NT, Atom ME, Atom XP, Atom 05... Just kidding.
How about AtomRSS X 1.0 Lynx
that
it'll be with us for a while. Per WG consensus, an Atom doc has no
version stamp. So there'll be no actual spec-based reason to call our
product Atom 1.0. But, we could just go ahead and do it anyhow.
Anyone have a better idea? --Tim
I like Atom.
non:serious response=joke
Foghorn
.
Seriously, I don't mind Atom 1.0 as long as the next version is
Atom 2.0. Please don't increment the right-of-the-dot part forever,
because I just had to fix some software that made the (reasonable)
assumption that 5.10==5.1, even though 5.10 is really Solaris 10.
wunder
--
Walter Underwood
71 matches
Mail list logo
