James,
what draft do you refer to?
Thanks,
Jan
On 19.03.2007, at 20:50, James M Snell wrote:
I'm assuming that since there was no additional expressed interest in
moving forward with the Atom autodiscovery draft that it's not
going to
go anywhere. My current intention is to go ahead
Hi Mark,
On Jan 5, 2007, at 6:21 PM, Mark Baker wrote:
On 1/4/07, Jan Algermissen [EMAIL PROTECTED] wrote:
I recall Mark Baker using something similar in his former RDF
Forms draft:
rf:Container xmlns:rf=http://www.markbaker.ca/2003/rdfforms/;
xmlns:rdf=http://www.w3.org
Hi,
on the NewsML list, an issue came up that due to they lack of a MIME type for
NewsML using NewsML as Atom content is somewhat problematic[1]; I think this is
the case with most of the more interesting XML applications out there.
Is there any chance to extend/revise Atom to allow an
On Sunday, December 17, 2006, at 11:02PM, Bob Wyman [EMAIL PROTECTED] wrote:
It is important to remember that not all processors of Atom data will know
what to do with unexpected metadata in the envelope. Thus, unexpected
envelope fields will often simply be stripped off and thrown to the bit
On Dec 17, 2006, at 10:13 AM, James M Snell wrote:
Quite frankly it doesn't matter what we call anything right now. The
server gets to determine what pieces of data it's willing to handle.
Period. If you want anything more than that, use webdav.
(Sorry if this has already been said or
Hi,
is it really true that the Atom namespace is http://www.w3.org/2005/
Atom ?
Meaning that it is somewhat difficult to identify Atom elements with
URIs:
http://www.w3.org/2005/Atomauthor
http://www.w3.org/2005/Atomconributor
Was that simply a mistake or a design feature when
On Dec 9, 2006, at 6:40 AM, Mark Baker wrote:
On 12/8/06, Asbjørn Ulsberg [EMAIL PROTECTED] wrote:
Both link relations are identical,
but the client has absolutely no clue before it GETs the URI
whether what
sits on the other end is an Atom Feed or an Atom Entry.
Nor should it need to
On Dec 8, 2006, at 6:49 PM, James M Snell wrote:
Not quite. What I'm implying is that not all applications have the
need
to implement the entire specification.
At this point it would be a really good idea to be clear about the
original
intention of the specification and then propably
On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote:
Considering you seem to only discuss their value from a feed reader
point of view
Hmm, strange. Feed readers are actually the last thing I am thinking
about wrt Atom (no intention to show disrespect for the blogosphere
of course).
before that
particular can of worms gets opened up.
Daniel E. Renfer
http://kronkltd.net/
On 12/7/06, Jan Algermissen [EMAIL PROTECTED] wrote:
On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote:
Considering you seem to only discuss their value from a feed reader
point of view
Hmm
To turn it a bit around: Would you ever want to subscribe to a single Atom
Entry? If not, wouldn't it be good to know that it was an Atom Entry and
not an Atom Feed before you started subscribing to it?
This is misleading wording (and maybe part of the overall problem)!
Following a link
On Wednesday, December 06, 2006, at 08:30PM, Antone Roundy [EMAIL
PROTECTED] wrote:
On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:
I'd say: stick with the one media type that is currently there -
there is no problem, just misconception about what it means to
subscribe.
A few
On Dec 6, 2006, at 11:01 PM, Asbjørn Ulsberg wrote:
On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen
[EMAIL PROTECTED] wrote:
This is misleading wording (and maybe part of the overall problem)!
Perhaps, but it describes one of the most important use-cases with
feeds -- which won't
On Dec 6, 2006, at 11:30 PM, James M Snell wrote:
Jan Algermissen wrote:
[snip]
So they should be fixed, should they not? They seem to only have
implemented half a media type.
The half they're interested in. Why aren't they interested in the
other
half?
Ha! Forget about the media
On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:
It seems pointless for atom:link to have a type attribute at all
then. You should be able to decide anything you need to decide by
GETting the resource (and sometimes parsing it). Why did we add
such a useless feature to the spec?
I am
farfetched, is it?
Let's just
label 'em differently and move on.
I still do not see the use cases justifying a new media type - it
might be the right thing to do but for the time being it looks like a
workaround.
Jan
- James
Jan Algermissen wrote:
On Dec 6, 2006, at 11:30 PM, James
On Dec 4, 2006, at 10:12 PM, Mark Baker wrote:
On 12/4/06, James M Snell [EMAIL PROTECTED] wrote:
All I can go on is evidence of how folks are actually using 'em...
and
they ain't using 'em as aliases. :-)
Ok, I'll take empirical evidence too 8-) Point the way ...
Question: what does
On Dec 5, 2006, at 9:15 PM, James M Snell wrote:
When I process this entry,
http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/
basic/10ge5k2k7c488algfbau5q9qc0
Funny, Safari switches to feed://www.google.com :-)
And then says it cannot process the entity (presumably
Maybe this perspective helps:
Is there any other media type that covers more than one document type
(root element in the case of XML, but could also be non-XML mime types)?
It would be interesting to see how those (if any) deal with the
issue. An example would maybe be iCalendar, Ithink.
On Nov 29, 2006, at 7:22 PM, James M Snell wrote:
One such problem occurs in atom:link and atom:content elements.
Specifically:
atom:link type=application/atom+xml href=a.xml /
atom:content type=application/atom+xml src=b.xml /
Given no other information I have no way of knowing
On Nov 29, 2006, at 5:16 PM, James M Snell wrote:
Create a new media type for Atom Entry Documents: application/
atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
That is a *very* good idea!!
+1
Jan
== Status ==
Proposed
== Rationale ==
The fact
Hi Mark,
would you suggest to put service and categories into application/atom+xml as
well?
Hmm, ah, I think I see what you mean: When a peer declares it understands
application/atom+xml the understanding of entry/ is mandatory anyhow. Despite
the additional inspection into the documents
On Nov 8, 2006, at 5:57 PM, Henry Story wrote:
http://www.intertwingly.net/wiki/pie/PaceSparqlLink
Are you really suggesting to use POST for querying (as the Pace says)?
You wouldn't even be able to send someone a link to the [feed that
is] the
query result or page through the result
dividing the query space into
subsets. Sorry about that.
On Nov 2, 2006, at 9:06 PM, Lisa Dusseault wrote:
On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:
If you aim to provide a REST interface, do not mimick a query
interface (at least not a complex one). Think of your 'asset
space
Gopalan,
On 26.10.2006, at 18:24, Gopalan Sri wrote:
Hello,
I am trying to use opensearch to do some paging of my search
results and
I have a question regard adding POST capabilities to the atom:link
construct.
atom link is not the appropriate place to do something like this. The
On 26.10.2006, at 18:24, Gopalan Sri wrote:
Hello,
I am trying to use opensearch to do some paging of my search
results and
I have a question regard adding POST capabilities to the atom:link
construct.
Gopalan,
could you reveal the use case that makes you think you need the POST
On 26.10.2006, at 18:24, Gopalan Sri wrote:to support something like this: link rel="next" href=""http://example.com">http://example.com/" type="application/atom+xml" action="" parameter name="q" xxx:Payload/ /parameter parameter name="blah" value="blah"/ /link If I understand
r time.Sri From: Jan Algermissen [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 26, 2006 3:05 PMTo: Gopalan SriCc: atom-syntax@imc.orgSubject: Re: Adding POST capability to atom:link On 26.10.2006, at 18:24, Gopalan Sri wrote: to supportsomething like this:link rel="next" href=
Hi,
RFC4287 distinguishes between 'undefined' and 'extension' constructs.
I am understanding the distinction to imply that conformant software
should provide for handling extension elements, but can and should
ignore any occurrences of undefinedAttribute or undefinedContent.
Is that
Hi,
is anybody working on (or planning to work on) a versioning extension
for Atom? I am about to use Atom in two (considerably different)
projects that require versioning and would be happy to join forces
and contribute real (enterprise-)world use cases. (Note: not
'enterprisey' use
On 12.09.2006, at 01:23, Tim Bray wrote:
On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote:
is anybody working on (or planning to work on) a versioning
extension for Atom? I am about to use Atom in two (considerably
different) projects that require versioning and would be happy
31 matches
Mail list logo
