On 20/3/07 9:00 AM, John Panzer [EMAIL PROTECTED] wrote:
Also, is there a standard way to discover the collection associated with a
feed? (Given that, if there is an IETF or WHAT-WG way to discover feeds,
there's an obvious way to discover collections... but I'm not clear on what
that would
On 17/12/06 1:13 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Lisa Dusseault [EMAIL PROTECTED] [2006-12-16 02:15]:
Since clients post Atom entries and other clients retrieve
them, it seemed reasonable to want to extend Atom
client-to-client. If I used AtomFu client that was able to
annotate
On 17/12/06 2:20 AM, Tim Bray [EMAIL PROTECTED] wrote:
I guess I'm assuming that one would want clients to be able to
extend Atom unilaterally.
That doesn't seem to have been a design goal for the WG. To the
extent that the issue never came up in the discussion.
Not sure exactly, but I
On 15/12/06 7:29 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
Besides, if you want to do fancy thing with a member, simply post a
media resource which is an atom entry. This won't be modified by the
server and will solely be treated a media resource.
promise? does the spec support this
On 12/12/06 5:56 AM, Kyle Marvin [EMAIL PROTECTED] wrote:
application/atom+xml; type=entry
application/atom+xml; type=feed
I believe other UA-visible Atom document syntax qualifiers will be
needed/coming downstream. For example. ones describing the expected extension
model(s) of the
On 11/12/06 2:26 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
Adding an optional parameter that indicated an entry or
a feed would be a more elegant solution:
application/atom+xml;type=entry
application/atom+xml;type=feed
I certainly agree it would be more elegant.
A more pragmatic
On 6/12/06 3:52 PM, James M Snell [EMAIL PROTECTED] wrote:
Not necessarily. Sure, it might be the same parser code, but not
necessarily the same bit of code using the parser. Look at the way
Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry
documents versus Feed
On 6/12/06 5:06 PM, James M Snell [EMAIL PROTECTED] wrote:
Would an agent finding multiple atom:content elements inside the one entry
consider that a problem (other than it being a spec violation)?
Are XML processors optimised for the fact that any given attribute can only
occur once per
On 1/12/06 5:21 AM, Antone Roundy [EMAIL PROTECTED] wrote:
5) Create a new media type for entry documents, and use @rel values
to solve issues that doesn't solve:
+/- Messy territory
If we were starting from scratch, I'd probably vote for #1. Since
we're not, I'd vote for #4 first,
On 30/11/06 5:39 AM, Henry Story [EMAIL PROTECTED] wrote:
would that not be solvable by
atom:link rel=entry type=application/atom+xml href=a.xml /
not if you want to do this:
atom:link rel=something-else type=application/atom+xml href=a.xml /
where 'something-else' might be 'comments' or
On 24/11/06 9:28 AM, Thomas Broyer [EMAIL PROTECTED] wrote:
Being a syndication feed is expressed by the media type, there's no
need for a 'rel' value.
I disagree, but for slightly different reasons. Consider these two links:
link rel=feed
type=application/atom+xml;type=feed
On 18/10/06 8:07 AM, Lisa Dusseault [EMAIL PROTECTED] wrote:
Extensions
When the client puts extension elements in a MER, MUST the server store those
unrecognized extension elements? I think the answer to this is actually that
servers often do not and should not be required to do so.
On 3/10/06 11:44 AM, James M Snell [EMAIL PROTECTED] wrote:
If the default direction for the entire document is RTL, allowing that
to be established at the feed or entry element level can save some
effort adding the appropriate controls to every text element.
so @dir is to be inherited by
On 4/10/06 1:03 AM, James M Snell [EMAIL PROTECTED] wrote:
A dir=rtl on the content element establishes the base direction for
the content but, just as with xml:lang, the content itself can override
the value using whatever mechanisms are native to the content type.
xml:lang doesn't go to
On 4/10/06 3:44 AM, James M Snell [EMAIL PROTECTED] wrote:
Either way, the behavior of the dir on the anchor is unmodified and
standard (X)HTML rules apply.
so how might you code this:
phere is some ltr text, with a link with
a href=..rtl-text/a which links to a
document which is
On 27/9/06 8:15 AM, Tim Bray [EMAIL PROTECTED] wrote:
PaceAppEdited: Lots of discussion. There seems universal support for
the utility of an app:edited element, and an assertion that entry
members SHOULD contain one. On the other hand, every discussion of
sort order has spiraled instantly
When updating an entry, is it acceptable to insert a value other than Now()
into atom:updated?
For example: Corporate Communications prep a release and they stamp it with
a release date of Monday 4 PM ... but I don't see this release update until
I get into the office at 2 PM Tuesday, and thus I
This took me quite a while to think through, but in the end I
agree. Translations of a resource will often have slightly different
contents in terms of the semantics of what is said, so I'd give them
different ids.
what would happen if you used conneg on the @rel='self' link (to the
entry/
On 27/7/06 7:42 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
what would happen if you used conneg on the @rel='self' link (to the
entry/ document), asking for a different language?
You mean, sending an Accept-Language request-header?
406 Not Acceptable or return the entry even if it does
On 30/6/06 1:34 AM, Bill de hÓra [EMAIL PROTECTED] wrote:
Which are clients supposed to respect in a conflict, the
Content-Language header or the xml:lang, ie, does XML On The Web Failing
Miserably, Utterly, And Completely extend to Content-Language+xml:lang?
xml:lang, if you think of xml
On 10/6/06 12:02 AM, James M Snell [EMAIL PROTECTED] wrote:
In the Feed License Draft, feed's a licensed independently of their
contained entries. There is no interaction between the licenses.
Ah, no inheritance. Makes sense really, since if that was in the spec it
would fail for aggregators
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
You mean `hreflang`, not `xml:lang`, right?
oops, yes.
I have to say at first blush I don¹t see why it should not work,
so I find your thought experiment quite amusing.
:-)
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
entry
link rel=replies thr:count=5 xml:lang=en href=1 /
link rel=replies thr:count=1 xml:lang=fr href=1 /
...
/entry
You mean `hreflang`, not `xml:lang`, right?
I also meant there to be different hrefs too :-(
entry
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
Apache would respond: well yes the file has
changed on the disk so here it is when in fact the content of the feed
has only changed for the number of comments of an entry.
so?
we have atom:updated to help aggregators detect
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I have to say at first blush I don¹t see why it should not work,
so I find your thought experiment quite amusing.
this should be amusing too:
entry
link rel=replies thr:count=5 href=1 title=trackbacks! /
link rel=replies
On 1/5/06 2:25 PM, James M Snell [EMAIL PROTECTED] wrote:
While I'm sure the other James may have his own particular set of
issues, the one pain point for me with the history spec is the use of
the previous link to point back in time. This runs counter to the use
of the previous link in
On 1/5/06 5:55 PM, James M Snell [EMAIL PROTECTED] wrote:
That said, however, we end up with a
problem when we have one spec that says next points backwards in time
(APP), one spec that says next points forwards in time (feed history)
and one spec that says next is just another page of
On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote:
Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI. Publisher
would need to make sure that the href/ref combo match up properly
Would this be considered a match?
link
On 13/4/06 8:02 AM, David Powell [EMAIL PROTECTED] wrote:
In terms of the considerations to the interoperability of running
code, thr:replies seems to beat atom:link in every way. It even
manages to be more concise (you don't need the @rel), and you wouldn't
need to put thr:count and
On 13/4/06 6:59 PM, David Powell [EMAIL PROTECTED] wrote:
But what would processors do with an atom:link? Atom Protocol uses
edit, there have been calls for a stylesheet. Links aren't
necessarily things that you'd display to users (check HTML out for
examples of that: favicon, P3P, Atom/RSS,
On 31/3/06 3:08 PM, Antone Roundy [EMAIL PROTECTED] wrote:
The escaped HTML content contained within the content element that
David was originally concerned with is more than likely a copy of
all or part of the elements and content contained inside the body
tag of the external document
On 24/3/06 4:42 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I'm getting the data by scraping an html page, so I'm expecting
it to be acceptable html code, including html entities.
Then decode the entities to a Unicode string and emit the feed as
Unicode. Simplest thing that will work
Hungarian names, the pattern is always surname
followed by forename - e.g. Bartók Béla, where Béla is the personal name and
Bartók is the family name.
While common western names (eg. Eric Scheid) would be indexed as Scheid,
Eric; a comma is instead simply added between the Hungarian surname
On 2/2/06 12:51 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Then again, I can¹t think of interesting
information to put in the referrer of regular feed poll requests,
but maybe my imagination is just too limited here.
Who said the aggregator would be limited to only doing regular feed polls?
On 31/1/06 1:27 PM, James Holderness [EMAIL PROTECTED] wrote:
Actually I was thinking just a regular href and type. For example:
link type=application/atom+xml
href=http://mydomain.com/feed;
hreflang=fr
x:id=french_entry_id
x:updated=2005-11-15T18:30:02X /
I'm not sure how valid that
On 26/1/06 4:23 PM, James M Snell [EMAIL PROTECTED] wrote:
thr:in-reply-to id=tag:example.org,2006:/some/entry
is that id for the thing being replied to, or the id of this thr:in-reply-to
element? if the former, is suspect idref would be more appropriate. but what
do I know?
e.
On 22/1/06 3:27 AM, Robert Sayre [EMAIL PROTECTED] wrote:
But, I could be in the minority. Which WG members think we should work
on exciting new HTML link relations?
Wow. Nobody.
Phil, could we get a new rev of the Autodiscovery I-D?
nobody likes a strawman.
e.
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by looking at the page without
On 20/1/06 7:52 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Here is a link to a resource:
link type=application/atom+xml href=... /
Please explain how a tool can decide whether that is a link to a
atom:feed document, or is a link to an atom:entry document?
this is an excellent point.
On 20/1/06 7:57 AM, James M Snell [EMAIL PROTECTED] wrote:
Here is a link to a resource:
link type=application/atom+xml href=... /
Please explain how a tool can decide whether that is a link to a atom:feed
document, or is a link to an atom:entry document?
This is a general
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
Not an entry but a feed. The autodiscovery is unambiguous on what such
a link points to.
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Okay, so you have two alternates: one with comments, one without.
That would be `rel=alternate` in both cases, with
`title=Entry` in one of them and `title=Entry with comments`
in the other.
This is semantically weak, I know.
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
And someone else still uses Atom in yet another clever way.
Which is precisely why [EMAIL PROTECTED]alternate,@type=atom+xml] is an
*ambiguous* way of discovering atom Feeds ...
It¹s just impossible to specify enough precise
On 20/1/06 8:52 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
Why wouldn't this work?
rel=alternate feed
rel=alternate entry
rel=alternate replies (see [1])
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
I.e. the values
On 20/1/06 8:31 AM, Robert Sayre [EMAIL PROTECTED] wrote:
First person to need the feature has to spec alternate entry instead
of making everyone change to alternate feed.
How is speccing alternate entry helpful?
That would *still* be considered an autodiscovery link to a feed,
according the
On 20/1/06 12:32 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:
Though at this point in this discussion, someone is always duty-bound
to point out that the only use of link that HTML actually specifies,
for stylesheets, treats them as not
On 20/1/06 1:55 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
What autodiscovery links should I do on a web page that displays a
single blog entry, like this one?
http://journals.aol.com/panzerjohn/abstractioneer/entries/1238
Actually on my blog each page has a feed associated with
it that
On 16/1/06 5:29 PM, Graham Parks [EMAIL PROTECTED] wrote:
Except no one bothered to tell the aggregator writers they'd have to
implement this, so no it's not safe.
so atom is good for schlepping documents about, but not for elements of
documents (with two exceptions) :-(
e.
On 17/1/06 2:21 AM, James Holderness [EMAIL PROTECTED] wrote:
the media resource is supposed to be stored external to
the collection feed and referenced via a content src link
hmmm ... premature optimisation due to common use case of binary content?
e.
Is this a valid atom entry?
entry
[...elided...]
summarya snippet of foo xml/summary
content type=application/foo+xml
foo:thing xmlns:foo=http://xmlns.com/foo/0.1/;
foo:nameKing George/foo:name
/foo:Person
/content
On 16/1/06 12:40 PM, Elliotte Harold [EMAIL PROTECTED] wrote:
No. It's not even well-formed much less valid.
ignore the typo.
e.
On 16/1/06 1:57 PM, James M Snell [EMAIL PROTECTED] wrote:
entry
...
entry type=whatever OPML's type is
opml:outline xmlns:opml=whatever.. ... /
/entry
/entry
Heh.. another typo methinks ;-)
grrr! TooEarly - SufficientCoffee = Typos
e.
On 16/1/06 2:09 PM, James Holderness [EMAIL PROTECTED] wrote:
The one time I'd think it might be safe is with XHTML (as I mentioned in a
previous message) since Atom processors are already required to handle XHTML
fragments in the content element. Anything else would be highly risky unless
On 16/1/06 3:46 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Thus, in the same sense I might have elsewhere a collection of
images, I have here a collection of atom categories.
That doesn¹t even work, because this is invalid:
entry
!-- ... --
content
On 21/12/05 3:53 PM, Michael Stillwell [EMAIL PROTECTED] wrote:
Is the link rel=via href=a.xml element the right way to do this?
the atom:source element is the right way.
e.
On 27/10/05 4:09 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
It would say descendents if it meant descendents, no?
not if it was speaking in more general terms.
e.
On 25/10/05 4:59 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I am asking if is there a generic way for an application to
implement alternate-link processing that gives sensible behaviour
for any type of main link.
link ..
x:alternate ...
/link
couldn't get more generic than that.
read it
On 25/10/05 5:17 PM, Henry Story [EMAIL PROTECTED] wrote:
link rel=enclosure type=audio/mpeg href=http://example.com/
file.mp3 xml:id=x-file
altlink:mirror href=http://www2.example.com/file.mp3; /
altlink:mirror href=http://www3.example.com/file.mp3; /
/link
It¹s a lot more
On 25/10/05 5:06 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Is providing a @title an option that a lot of people would use
and/or someone out there cannot do without?
In Atom 1.0 not enough deployment to say
In HTML ... *lots* of current practice of labelling mirrors with the org
name
On 24/10/05 5:31 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
This has not yet proven to be really needed (e.g. the Top 50 web site I
saw didn't provide archives of previous rankings).
When there'll be such a need, then we'll define a new link relation (I
already proposed archives/history to
On 25/10/05 3:43 AM, James Holderness [EMAIL PROTECTED] wrote:
My only suggestion would be using rel=enclosure on the inner links rather
than alternate. There will be some Atom processors [1] that won't be able
to tell the difference between an inner link and an outer link.
and we're back to
On 25/10/05 8:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
You have to split on whitespace; that¹s much easier in my book
than finding a nodeset of nested elements and iterating over it.
I recall people screaming about micro-parsers before for a different
attribute. Has anything changed?
e.
On 25/10/05 5:48 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
link
rel=enclosure type=audio/mpeg
href=http://example.com/file.mp3;
encl:mirrors=http://www2.example.com/file.mp3
http://www3.example.com/file.mp3;
xml:id=x-file
/
link
rel=alternative-enclosure type=application/ogg
On 25/10/05 1:12 PM, James M Snell [EMAIL PROTECTED] wrote:
+1 to Eric's -1. Let's keep it simple.
link rel=... type=... href=...
x:alternate type=... href=... title=... /
/link
I'm also liking it from another angle...
With some of the other approaches dumb clients do harm to others,
On 25/10/05 8:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
If you want a concrete reason, it requires extra parsing
whereas everything else would be automatically parsed by the
XML library.
You have to split on whitespace; that¹s much easier in my book
than finding a nodeset of nested
On 23/10/05 1:14 AM, James M Snell [EMAIL PROTECTED] wrote:
The challenge with using alternate to point to files of different types
is that why would someone do (a) when they can already do (b) without
the help of a new extension
(a)
link rel=enclosure type=audio/mpeg
On 22/10/05 1:33 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
First, rel=self is going to be implemented by most everything
that groks Atom 1.0 in order to support one-click subscription,
if applicable, right? Whereas this new relationship might not
find such wide-spread support.
I believe
On 22/10/05 4:48 AM, James M Snell [EMAIL PROTECTED] wrote:
Note the caveat, with the same combination of type and hreflang
attribute values. The idea is to prevent a single license from being
appearing more than once.
Multiple license link relations MAY be used to indicate that the
+1 to all
Ok, somehow this slipped under the radar on me during
my first reading. -1, as I prefer next, as in, the *next*
document in a chain of documents.
No matter which direction you head in, no matter which way the chain is
sorted, the next document is always next, so that's not a useful
On 18/10/05 3:32 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
Such agents should also take care to detect circular
references between feeds when following them.
s/between feeds when/between feed documents/
otherwise +1
e.
On 18/10/05 6:14 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
Yes, and navigating through the historical states of the feed resource is
not paging, it's more like having access to archives.
I was thinking about proposing yet another link relation archives: in
the general use case, it would
On 18/10/05 5:51 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
How can there be more than one paging semantic applied to a single feed?
If a feed (not feed document) is a set of entries (sorted by whatever
metadata: updated, priority, relevance, etc.) and you publish chunks as
many feed
On 19/10/05 5:38 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I already have code that uses next for this. Why do we want to change it?
Why did you choose next?
e.
On 19/10/05 9:13 AM, Robert Sayre [EMAIL PROTECTED] wrote:
rel: next
definition: A URI that points to the next feed in a series of feeds.
For example, in a reverse-choronological series of feeds, the 'next'
URI would point deeper into the past.
How will your code cope with a
On 17/10/05 9:30 PM, Lindsley Brett-ABL001 [EMAIL PROTECTED]
wrote:
I would like to toss out another thought - since the updated time of a
feed is required, maybe it can be used to help determine the feed
order/history.
For example, if following a next link (or pick your favorite term), if
On 18/10/05 12:43 AM, James Holderness [EMAIL PROTECTED] wrote:
Eric Scheid wrote:
I'd prefer that our use of 'prev' and 'next' be consistent with other uses
elsewhere, where 'next' traverses from the current position to the one that
*follows*, whether in time or logical order. Consider
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote:
I'd prefer that our use of 'prev' and 'next' be consistent with other uses
elsewhere, where 'next' traverses from the current position to the one that
*follows*, whether in time or logical order. Consider the use of
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote:
Can self be polymorphic--the subscription URI in the live end of a
feed, and this chunk in a historical chunk? Can an extension speak
authoritatively about the meaning of something from the core spec?
If it were so, and you were
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote:
2) Search results, where the order of everything all along the entire
chain shifts around all the time.
BTW, case 2 destroys the idea of a fixed end and a live end.
Case 2 would be a closed set, generally speaking.
geeking
On 18/10/05 4:39 AM, James Holderness [EMAIL PROTECTED] wrote:
Eric Scheid wrote:
Ask yourself these questions: which is the first message in this thread,
and if you wanted to understand the thread would you start there, or at the
most recent entry in this thread and read backwards
On 18/10/05 9:53 AM, Mark Nottingham [EMAIL PROTECTED] wrote:
So what happens when you need the rel=self (as currently defined)
of an archive feed?
The current definition being ...
The value self signifies that the IRI in the value of the href
attribute identifies a resource
On 15/10/05 8:28 AM, Henry Story [EMAIL PROTECTED] wrote:
Is the 'first' the feed document that changes, whereas 'next' and 'last'
point to the archives? (in a feed history context?)
My thinking is that of the two ends, 'first' and 'last', it would normally
be the 'first' end that is
On 12/10/05 7:54 PM, Pascal Philippe [EMAIL PROTECTED] wrote:
I would like to try to understand why we can't have more than one
atom:content element within an atom:entry element. Could you give me
the reason of this choice?
IIRC, it was thought it would be too burdensome for developers to
On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote:
Excellent. If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections into a
single set of paging link relations (next/previous/first/last).
'first' or 'start'?
Do we
On 14/10/05 2:01 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
Eric,
It's like deja-vu all over again.
http://bitworking.org/news/Atom_Auto_Sub_How_To
:)
I'd forgotten about that, I was only remembering the wiki.
I still think it odd that one could traverse both prev and next from the
On 10/10/05 2:02 PM, James M Snell [EMAIL PROTECTED] wrote:
* dcterms:valid has slightly more functionality in that you get to
specify a start date.
I don't necessarily want more functionality. The atom:updated date
gives us a perfectly good start date.
Perhaps atom:published would be
On 2/10/05 3:54 PM, James M Snell [EMAIL PROTECTED] wrote:
As I've been going through the effort of defining a number of Atom
extensions, I've consistently come back to the thought that it would be
interesting to explore the creation of a Common Extensions Namespace
under which multiple
On 21/9/05 1:05 PM, James M Snell [EMAIL PROTECTED] wrote:
The ranking is part of the entry metadata. If an entry falls off the
feed, there is no effect on the ranking metadata. With partial feed
retrieval, ordering could be performed over the entire set of entries.
How does this help (eg)
On 21/9/05 9:35 PM, James Holderness [EMAIL PROTECTED] wrote:
Marking entries as having no rank sounds like a nice idea, but I don't think
it's feasible in the long run.
thinking more ... I think the way to handle this is that the client
application could weight the ranking with the age of
On 21/9/05 5:18 AM, James M Snell [EMAIL PROTECTED] wrote:
For instance
feed
entry
...
i:rank10/i:rank
/entry
entry
...
i:rank5/i:rank
/entry
/feed
What happens when entries fall off the bottom ... do their rankings
expire? How does that work with the
Tis be gettin' t' th' time o' year when pirates be stalking th' deck. Arrr!
(I can't keep that up...)
there's a serious point ... I've just had the dubious pleasure of seeing a
couple of subscriptions have all their entries marked as changed/unread, and
on inspection I see they've flipped the
On 15/9/05 6:06 AM, David Powell [EMAIL PROTECTED] wrote:
Eg - An Atom library or server that doesn't know about this extension
is free to not preserve the entry order, and yet to retain the
fi:ordered / element, even though this will have corrupted the data.
very good point.
e.
On 12/9/05 9:00 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Henry Story [EMAIL PROTECTED] [2005-09-12 00:05]:
In the DOAP over Atom type solution where the RDF is placed
inside the content, there is then no more space to put the
entry content itself. So I can either put the text entry into
On 7/9/05 11:09 PM, Roland Jungwirth [EMAIL PROTECTED] wrote:
When going through the Atom specification regarding syntax
(http://ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt), I
came to point 4.1.1 The atom:feed Element. This states that every
atom:feed element has to have one
On 31/8/05 7:50 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Is not logical order, if any, determined by the datetime of the
published (or updated) element?
No. I've seen a few things online where they publish chapter 3 first,
followed by chapter 8, and then go back and fill in the blanks.
On 31/8/05 6:01 AM, Mark Nottingham [EMAIL PROTECTED] wrote:
It sounds like you've got use cases for Atom that other use cases
(e.g., lists) make difficult to work with. Banning those other use
cases makes things easier for you, but I don't think it's good for
Atom overall.
those other use
On 30/8/05 11:19 AM, James M Snell [EMAIL PROTECTED] wrote:
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=no /
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=yes /
content src=http://www.example.com/enclosure.mp3; x:follow=no /
content
On 30/8/05 12:05 PM, James M Snell [EMAIL PROTECTED] wrote:
That's kinda where I was going with x:follow=no|yes. An
x:archive=no|yes would also make some sense but could also be handled
with HTTP caching (e.g. set the referenced content to expire
immediately). x:index=no|yes doesn't seem
On 26/8/05 3:55 PM, Bob Wyman [EMAIL PROTECTED] wrote:
Remember, PubSub never does
anything that a desktop client doesn't do.
Periodic re-fetching is a robotic behaviour, common to both desktop
aggregators and server based aggregators. Robots.txt was established to
minimise harm caused by
1 - 100 of 319 matches
Mail list logo
