Re: Autodiscovery Draft

2007-03-19 Thread Eric Scheid

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 be.  I do think that collection autodisco is important.)

please remember that there may be multiple collections collated into one
feed ... and that various members of one collection may be represented in
many different feeds.

it's not 1:1.

e.



Re: AD Evaluation of draft-ietf-atompub-protocol-11

2006-12-17 Thread Eric Scheid

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 my entries automatically with what music I was
 listening to (track name, album and artist in XML elements)
 while I wrote a blog posting, I thought AtomFu should just
 store that as XML markup in the entry.
 
 That is, IMO, a misconception about Atom ­ one that is frequently
 seen. We just had a similar discussion tonight in #atom on the
 Freenode IRC network. The track name, album and artist are data;
 they should be part of the payload of an entry, not part of its
 envelope. In practice, that means you use either microformats or
 a more structured format than HTML. Extending the Atom envelope
 is a strategy of last resort.

wha?

What music Lisa is listening to when she wrote a blog posting is meta data,
not content, unless of course she's writing a blog posting *about* that
particular bit of music. The music is contextual meta data, along the same
vein as geo location of circumstance, the atom:generator involved, and even
the atom:published date/time.

Since when are we calling atom entries envelopes?

e.




Re: AD Evaluation of draft-ietf-atompub-protocol-11

2006-12-16 Thread Eric Scheid

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 did raise the possibility of a client passing in XML
whose only purpose is for the benefit of other clients. Things like
editorial comments and such. These would have been shepherded in the
app:control element, and there was a great deal of discussion about the
contents of app:control not being published (whatever that meant).

It got hairy, and there wasn't much support for the idea.

e.



Re: AD Evaluation of draft-ietf-atompub-protocol-11

2006-12-14 Thread Eric Scheid

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 assertion? or is this another case of
the server is in charge and can accept or change whatever it wants?

e.



Re: Atom Entry Documents

2006-12-11 Thread Eric Scheid

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 target Atom document.  Feed vs. entry is just one syntax
 variant of an Atom document, others of UA interest might be this is an Atom
 document containing OpenSearch results or this is an Atom Document that
 describes media using Media RSS extensions.

I'm not so sure. I see the difference between the two being one vs many,
and nothing more. What you want could however be accommodated by additional
parameters..

 I'm not sure that treating each syntax variant as a unique MIME type is a
 scalable approach for the long haul.  One specific issue is that you will also
 have to deal with combinations (ex this Atom document is a feed that contains
 OpenSearch results listing Media RSS entries).

application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS

(or syntax to that effect)

e.



Re: PaceEntryMediatype

2006-12-10 Thread Eric Scheid

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 solution would be to go with application/atom.entry+xml
... if WHATWG don't update their spec, we're safe; if anyone has implemented
per the current draft WHATWG spec, we're safe; if any implementations use
naïve string matching, we're safe. The only danger is if someone has
implemented APP per the moving target which is Draft-[n++] ... they should
revise their test implementations as the draft updates, and certainly update
once it reaches RFC status, so no sympathies there.

e.




Re: PaceEntryMediatype

2006-12-05 Thread Eric Scheid

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 documents.  The majority of applications that most
 frequently handle Atom Feed Documents have no idea how to deal with Atom
 Entry Documents and I would wager that most applications that understand
 how to process Atom Entry Documents and Atom Feed Documents typically
 don't fall into the same category as most feed readers.

If an agent found an entry document, should it assume that it's a feed with
one entry (so far) and allocate resources accordingly (ie. allow for
cardinality of n++)?

If an agent found an entry document, and then later returned to find a feed
containing multiple entries, would it consider that a problem?

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 element, and not twice or more .. eg. foo attr=1 attr=2
/ ?

e.



Re: PaceEntryMediatype

2006-12-05 Thread Eric Scheid

On 6/12/06 4:32 PM, Mark Baker [EMAIL PROTECTED] wrote:

 Or, are there applications which only process entry documents and not
 feed documents?

That would be unusual. I can imagine though that an application would easily
be designed to expect only entry documents for specific situations. An
editor application, for example, would know how to handle collection feeds
and entry documents, but would reasonably not be expected to know what to do
if it retrieved a feed document when attempting to edit a specific entry
(especially if it PUT/POSTed the entry as an entry document in the first
place).

Similarly, if an atom:entry element was wrapped inside some other unexpected
XML document (eg. RSS 1.0) ... should applications be prepared to cope with
that?
e.



Re: PaceEntryMediatype

2006-12-05 Thread Eric Scheid

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 element, and not twice or more .. eg. foo attr=1 attr=2
 / ?
 
 
 Ok, you lost me on these last two. I'm not sure what you're getting at.

It's just the cardinality question in a different context. Argument by
analogy.

e.



Re: PaceEntryMediatype

2006-11-30 Thread Eric Scheid

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, and perhaps #5 second, but I'd have
 to think about #5 more first.

Starting from scratch, idealised, I'd want different media types (or params)
for entry documents and feed documents, and link type which clearly
indicates this is for subscription, as distinct from this is an alternate
representation, this is an archive, etc.

Using the two mechanisms together allows combinations such as here is a
feed you can subscribe to of the comments for this entry and here is a
feed document listing related resources, but since it won't likely be
updated don't bother subscribing.

I'd like to be able to use a lot of the link types we currently use for html
(directory, help, toc, related, next, etc) to refer to resources which
happen to be serialised in the atom feed document format, and feel safe in
knowing they won't be automagically treated as being subscription feeds.

e.



Re: PaceEntryMediatype

2006-11-29 Thread Eric Scheid

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 'history' or 'unexpurgated' or
'disemvowelled' or many other as yet unknown opaque-strings, some of which
would be used when linking to feed documents, some when linking to entry
documents.

e.



Re: PaceResurrectAutodiscovery

2006-11-23 Thread Eric Scheid

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 href=/latest.atom /
link rel=alternate
type=application/atom+xml;type=feed href=/2006/10.atom /

They are both Atom Feed Documents, but the former is the syndication feed to
which one would reasonably subscribe to for delivery of more content like
you're looking at, and the latter is simply an alternate representation of
the current content (in this case being an archive page for October 2006),
and subscribing to it would be foolish.

Also, how do we have syndication feeds in different representation formats
(eg. RSS), or are you proposing the ;type=feed gets appended to all the
various media types as needed?

 The feed keyword indicates that the referenced document is a
 syndication feed. If the alternate link type is also specified, then
 the feed is specifically the feed for the current document;
 otherwise, the feed is just a syndication feed, not necessarily
 associated with a particular Web page.

There's a third case they don't mention here, which is if 'alternate' is
used but 'feed' is not also specified ... in which case it's not a feed in
the sense of a source of continuing updates, but more like a static resource
(subject to the usual bit rot and tweaky updates).

The three cases are:

@rel=feed
@rel=alternate feed
@rel=alternate

Would be nice if there was an RFC we could point at which clarified what is
meant by each. Would go a long way towards overcoming deployment inertia.

e.



Re: AD Evaluation -- extensions

2006-10-17 Thread Eric Scheid

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.  That makes it hard
 for clients to extend AtomPub's syntax in ways that other clients will
 understand but servers don't care about.  Consider the consequences: when some
 enterprising client developer decides to do something cool and useful and
 encounters servers that don't store their metadata in the obvious place, the
 client developer is going to quickly work around that by storing in some
 unobvious place.  For example in HTML comments in the atom entry content, or
 microformats, etc.  Is that all cool?  

This issue also has implications on what extensions are passed through to
the published feed ... a client might insert some extension metadata they
want published (eg. geo-coordinates), and a client might insert some
extension metadata they only want visible within the collection feed (eg.
editor workflow comments) ... with the understanding also that if the server
actually understands a particular extension it might result in extensions
being added/modified outside of the bucket (eg. ext:include
trackbacks=yes / resulting in lots of link/ elements being added)

We did at one time discuss providing a bucket container specifically for the
latter, with the assumption that extensions outside the bucket are data
elements meant for publication. Having a bucket container would make life
simpler for server implementations -- just store everything as an xml blob,
the same as they do for atom:[EMAIL PROTECTED]

Lisa, would that help?

e.




Re: Atom and bidi

2006-10-03 Thread Eric Scheid

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 contained elements (similar to how xml:lang
and xml:base is)?

what happens with content src=.. dir=rtl / ?

e.



Re: Atom and bidi

2006-10-03 Thread Eric Scheid

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 a child (embedded) document.

 The  language specified by  xml:lang applies to the element where
 it is specified  (including the values of its attributes), and to all
 elements in its content unless overridden with  another instance of
 xml:lang.

what happens here?

a href=.. dir=rtl .. yadda .. /a

e.



Re: Atom and bidi

2006-10-03 Thread Eric Scheid

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 ltr-text/p

I know the difference between @xml:lang and @hreflang ... so which is @dir
analogous to?

e.



Re: WG Last Call for draft-ietf-atompub-protocol

2006-09-26 Thread Eric Scheid

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 into a rat-hole.
 
 Conclusion.  PaceAppEdited is accepted, in part. The second part of
 the proposal, defining the app:edited element, is ACCEPTED.  The
 first part, imposing a requirement on the sort order of collections,
 clearly does not have consensus support.

There also seems to be universal support for the notion that collection
feeds could be sorted by something other than what's currently in the spec.
The spec currently not only says collections are to be sorted by
atom:updated, but because of the MUST it also says it MUST NOT be sorted by
anything *else*, which is a problem.

Section 10.0 ¶ 2 says this:

The entries in the returned Atom Feed MUST be ordered by their
   atom:updated property, with the most recently updated entries
coming first in the document order. Clients SHOULD be constructed
in consideration of the fact that changes which do not alter the
atom:updated value of an entry will not affect the position of
the entry in a Collection.

We need to either strike that entire paragraph, or at the very least make
that MUST into a SHOULD.

I say +1 to s/MUST/SHOULD/

e.




atom:updated - not now() values?

2006-08-13 Thread Eric Scheid

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 quickly enter it into the
CMS and set the atom:updated value to Monday 4 PM.

e.



Re: Language Negotiation

2006-07-27 Thread Eric Scheid


 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/ document), asking for a different language?

e.



Re: Language Negotiation

2006-07-27 Thread Eric Scheid

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 not match the
 accepted languages.
 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7

so, do not return the requested language alternate?

e.



Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt)

2006-06-29 Thread Eric Scheid

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 being nested.

in other words, what is the lang of the atom:content below:


HTTP 200 OK
Content-Language: ch
...

feed xml:lang=fr ...
entry xml:lang=it
content xml:lang=en ...
...
/content
...
/entry
...
/feed

e.




Re: Copyright, licensing, and feeds

2006-06-09 Thread Eric Scheid

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 that are not aware of that inheritance.

e.



Re: Feed Thread in Last Call

2006-05-17 Thread Eric Scheid

On 17/5/06 11:38 AM, James M Snell [EMAIL PROTECTED] wrote:

 This will be fixed in the next revision of the draft.  The short answer
 is: every replies link MUST be processed independently of any others.
 That is, the feed consumer MUST NOT assume that multiple replies links
 are all just pointing at different representations of the same set of
 responses.

would this mean this is possible:

entry
link rel=replies thr:count=5 xml:lang=en href=1 /
link rel=replies thr:count=1 xml:lang=fr href=1 /
...
/entry

e.



Re: Feed Thread in Last Call

2006-05-17 Thread Eric Scheid

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.

:-)




Re: Feed Thread in Last Call

2006-05-17 Thread Eric Scheid

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
link rel=replies thr:count=5 hreflang=en href=1 /
link rel=replies thr:count=1 hreflang=fr href=2 /
...
/entry


e.



Re: Feed Thread in Last Call

2006-05-17 Thread Eric Scheid

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 if there has been a
significant change ... everything else is just meta data.

e.



Re: Feed Thread in Last Call

2006-05-17 Thread Eric Scheid

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 thr:count=1 href=2 title=comments! /
...
/entry

e.




Re: Tools that make use of previous/next/first/last links?

2006-05-01 Thread Eric Scheid

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 both OpenSearch, APP and Gdata.

I thought OpenSearch results are not sorted by chronological age at all, but
instead by relevance? Using next with OpenSearch makes sense in that
context. Using previous for stepping back thru time in a data store
arranged chronologically makes sense.

I'm not familiar with how Gdata arranges it's data, but briefly scanning the
API docs it's modelled on OpenSearch, and furthermore it says Result
ordering is up to the implementation ... thus I would think it would be
right for it to use 'next' to get the next page, but wrong to assume that
this would imply stepping backwards chronologically.

e.



Re: Tools that make use of previous/next/first/last links?

2006-05-01 Thread Eric Scheid

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 entries that match
 some criteria (opensearch). No matter what the various link types point
 to, there needs to be consistency. As it stands now, a single feed
 cannot implement APP, OpenSearch AND Feed History.

I just reviewed the relevant example in the APP spec and it's worrisome.
Reading between the lines it suggests that the subscription uri is
http://example.org/entries/go;, with the rest of the collection available
via rel=next through to http://example.org/entries/10;.

The worrisome thing is that once that collection gains another 10 entries,
then the resource http://example.org/entries/11; will now contain the
entries which were previously contained by resource
http://example.org/entries/10;. Every page of the collection needs to be
updated and have the entries shuffled along.

A simplified example:

/entries/go contains entries Q,R,S,T
/entries/2 contains entries M,N,O,P
/entries/3 contains entries I,J,K,L
/entries/4 contains entries E,F,G,H
/entries/5 contains entries A,B,C,D

which then gets another 4 entries added (ie. U,V,W,X) and the collection now
looks like this:

/entries/go contains entries U,V,W,X
/entries/1 contains entries Q,R,S,T
/entries/2 contains entries M,N,O,P
/entries/3 contains entries I,J,K,L
/entries/4 contains entries E,F,G,H
/entries/5 contains entries A,B,C,D

This is just smells bad in so many ways. Pity the blog package that
publishes static files and will have to rebuild every collection page. Pity
the poor server that gets asked if /entries/3 has been modified and if so
hand it over. Pity the google bot that does all that asking.


Of course, this sentence doesn't parse into English real well either:

next and prev link elements reference the
preceding and subsequent feed documents in the set.

ie. next references the *preceding* feed document, and prev references
the *subsequent* feed document. It doesn't even make sense when read Down
Under ;-)

e.



Re: Feed Thread Draft Updated

2006-04-21 Thread Eric Scheid

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 rel=replies
href=comments
xml:base=/06/04/21/blah/ /
  thr:count ref=/06/04/21/blah/comments
 updated=...5/thr:count

You just know there'll be a few idiots that will try that on.

e.



Re: Feed Thread Draft Updated

2006-04-13 Thread Eric Scheid

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 thr:when into a namespace (namespaced
 attributes confuse people).

atom:link beats thr:replies on the basis that I don't need to understand
what replies are to discover that there is a link from this thing to that
thing.

atom processors know what atom:link is, but it wouldn't know what to do with
this:

 xyz:qwerty foo=opaque-string
   bar=opaque-string
   qaz=opaque-string
   zak=opaque-string /

e.



Re: Feed Thread Draft Updated

2006-04-13 Thread Eric Scheid

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, GRDDL)

as I understand it, dereferencing the 'edit' link returns a representation
of the entry which is suitable for editing (ie. it contains all the bits
needed).

as to the other link types in html ... I hope we've learned something from
that experience since then.

e.



Re: Does xml:base apply to type=html content?

2006-03-30 Thread Eric Scheid

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 referenced by an associated link
 element, and therefore no guarentee that the xml:base of the atom
 feed is going to be anywhere even close to accurate.

I'm doing something similar right now, scraping some website that doesn't
provide feeds for what I want. I check the html of the page I scraped and if
they have a base I use that, else I use the URL I used to fetch the page.

The tag soup I extract for each entry contains relative references. I really
don't want to go fixing that tag soup so I just stick that base url into
xml:base for each entry (and not just at the top of the feed, because I'm
scraping paginated results).

e.



Re: atom:name ... text or html?

2006-03-23 Thread Eric Scheid

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 reliably.

I figured as much. Oh well, now to track down a list of html entities and
their corresponding unicodes ...

e.



Re: Atom syndication schema

2006-03-14 Thread Eric Scheid

On 15/3/06 2:21 PM, Martin Duerst [EMAIL PROTECTED] wrote:

 Not sure if this is a known bug, but I just noticed that the RelaxNG
 grammar doesn't accept atomCommonAttributes (eg xml:lang) on the
 atom:name and atom:uri and atom:email elements used within
 Person constructs.
 
 For atom:uri and atom:email at least, not having xml:lang may
 be seen as a feature. While these often contain pieces from one
 language or another, they are not really in a language.

Since the original discussion I've stumbled across something extra that
makes xml:lang relevant for atom:name.

Seems that in writing 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 and
forename, making Hungarian names indistinguishable from other Western-style
names. For example: Bartók Béla is indexed as Bartók, Béla.

Icelandic names are another game altogether.

e.




Re: Browser behaviour

2006-02-01 Thread Eric Scheid

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?

My aggregator of choice lets me browse the links in entries, including any
atom:links ... no reason it couldn't thus fetch a linked resource, and
specify the current feed as the referrer.

e.




Re: todo: add language encoding information

2006-01-31 Thread Eric Scheid

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 is considering a client that didn't understand
 this extension would consider the full feed to be an alternative for that
 one particular entry which doesn't seem right.

Any reason that application/atom+xml document couldn't be an Atom Entry
Document, apart from the current lack of reader/browser support? It could
also then include the links necessary to subscribe to the specific language
feed.

e.



Re: Feed Thread Draft

2006-01-25 Thread Eric Scheid

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.



Re: new draft? (was: invention)

2006-01-21 Thread Eric Scheid

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.



Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 spidering. But `rel` does not
 add any information.

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?
 
 In fact, semantically, we should be encouraging people to move
 things out of their `link`s and into `a`s in the page.

Sounds like PaceAnchorSupport. How do you propose we do this encouragement,
if not by codifying it into a spec?

On 20/1/06 4:05 AM, Robert Sayre [EMAIL PROTECTED] wrote:
 The spec is extremely well-written and reflects existing behavior.

The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That doesn't meet my definition of well-written.

e.




Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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. How does either Pace address it?

PaceDifferentRelValue addresses this. It suggests using feed as an @rel
value to indicate the referenced resource is a feed (ie. is not an entry
doc) which can be subscribed to. It doesn't rule out continuing to use
alternate for those cases where the feed is actually an alternate to the
current document.

 I am trying to think of a scenario where I¹d want to autodiscover an entry
 document (as opposed to simply linking to it) and the inability to distinguish
 between feed and entry documents is causing a problem, but I can¹t come up
 with anything. Can you provide an example?

I'm not talking about autodiscovery of entry documents. I'm talking about
autodiscovery of feeds, which (and this is the point) is *different* from
autodiscovery of resources with the mime type of application/atom+xml.

Apart from Atom Entry Documents, there are also application/ref+xml
documents ... and not all of those are RSS 1.0 feeds.

Using feed solves the problem for both cases (atom entry and rdf+xml), and
potentially any similar problems (eg newsml+xml?).

e.




Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 limitation of the media type definition, not with the
 autodiscovery draft.  We have the same problem differentiating
 atom:link type=application/atom+xml href=... /.  This isn't a
 problem that the autodiscovery draft needs to solve.  If it's a problem,
 solve it in the Atom format spec where the media type is defined.

Too late. It would have been nice to have application/atomentry+xml

Also, fixing it in the atom format spec doesn't fix the exact same problem
autodiscovery has with application/rdf+xml.

e.



Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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.

Unambiguous? The autodiscovery spec does not outlaw using
[EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry
documents. It only says that such links may be used to find Atom Feed
Documents. This is a subtle nuance.

e.



Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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.

@rel contains tokens, @title contains human language content.

Would @title=Entrada com comentários also be acceptable? How about
@title=Entrata con le osservazioni or @title=Entrée avec des
commentaires or @title=Entrada con comentarios or @title=Eintragung mit
Anmerkungen? No. This is no basis for auto-whatever.

No matter what the @lang might be, the @rel would still contain the same
token for each of those possible @title links. It's just English Language
Imperialism why it happens to be alternate entry, it could just as easily
be specced to be FooBarBaz or 3576.24352.987.

e.




Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 semantics to cover
 everyone¹s use cases, and no single app will ever understand all
 of these disparate semantics.

Strawman. I'm not suggesting we pre-define all these other cases. I'm
suggesting we define this one case (here is a feed document related to this
page) in a manner which distinguishes it from other [undefined] cases.

 The problem seems simple while you
 look at it with blog-coloured glasses because that is such a
 small and well-understood niche of the problem space.

Be careful what you assume. I'm thinking of using atom entry documents for
many non-blog related purposes, and this is what is driving my interest in
disambiguating feed autodiscovery.

e.




Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 are all orthogonal.

Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links

 rel=alternate href=1
 rel=alternate href=2
 rel=alternate href=3
 rel=feed  href=1
 rel=entry href=2
 rel=replies   href=3

Which is exactly what was intended.


e.



Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 current autodiscovery spec. That's the problem right there.

The spec should allow for the creation of other specs without land-grabbing
the non-specific alternate @rel value.

e.



Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 orthogonal (alternate stylesheet
 is not alternate and a stylesheet, it's an
 alternate-stylesheet), and further assigns meaning to the presence
 (though not, exactly, the content) of a title attribute.
 
 Marvelous.

Yeah, awful.

 Are you suggesting we promulgate that behaviour in
 the face of autodiscovery for RSS that already uses
 alternate?

Speaking for myself, quite the opposite.

Robert Sayre is the only one so far suggesting that @rel=alternate entry
should be treated as excluding the semantic of @rel=alternate. Which is
surprising: I would have bet he would consider the alternate stylesheet
thing an abomination.

I'm suggesting that if we want to link to a resource which is considered to
be a feed for the current document we use feed. If we want to link to a
resource which is considered to be an alternate representation of the
current document we use alternate. If the resource is considered to be
both, then the x/html spec allows both relationships to be expressed in the
one link as a space separated list.

Specifying feed does not rule out using alternate feed for backwards
incompatibility purposes, except to those implementations that can't cope
with more than one value in @rel, and according to the autodisco 1.0 spec
they are broken anyways so I have no compassion for them.

e.



Re: finishing autodiscovery, like now

2006-01-19 Thread Eric Scheid

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 is a feed of all the comments on that page.

Are the comments on the same html page, or on another page? Some websites do
it the latter way. It often depends on the size of the article, especially
if the article is split into multiple pages (eg.
http://www.xml.com/pub/a/2005/12/07/catching-up-with-the-atom-publishing-pr
otocol.html ).

In the first use case, it would make sense to have @rel=alternate feed
replies (it's an alternate representation of the page, it's a feed of
updates of this page, and it's a resource containing replies to this page).

In the latter case however @rel=alternate feed replies would be broken.
The replies are not on that page, so how is a feed of replies an alternative
representation? It would make sense to have @rel=related feed replies
though.

 Regardless, the current spec is unambiguous, it points to
 feeds. If we want it to point to something besides a feed
 it has to be changed.

No, it does *not* point to feeds, it points to resources of a certain mime
type of which a subset are feeds. There's the ambiguity.

e.



Re: partial xml in atom:content ?

2006-01-16 Thread Eric Scheid

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.



Re: partial xml in atom:content ?

2006-01-16 Thread Eric Scheid

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.



partial xml in atom:content ?

2006-01-15 Thread Eric Scheid

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
/entry

That is, is a partial xml document valid inside the atom:content element?
What about xml formats whose specs state that there must be a certain root
element (similar to how atom documents must have either feed or entry as
root elements)?

e.



Re: partial xml in atom:content ?

2006-01-15 Thread Eric Scheid

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.



Re: partial xml in atom:content ?

2006-01-15 Thread Eric Scheid

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.



Re: partial xml in atom:content ?

2006-01-15 Thread Eric Scheid

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
 it was a proprietary feed communicating between two known applications.

then you're not going to like what I was thinking of doing ... posting
atom:category / chunks to an APP/media collection, such that the media
collection entry might look like this (no typos this time, I hope)...

entry
...
content type=application/atom+xml
category .../
/content
/entry

Thus, in the same sense I might have elsewhere a collection of images, I
have here a collection of atom categories.

I can hear the screaming already.

e.



Re: partial xml in atom:content ?

2006-01-15 Thread Eric Scheid

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 type=application/atom+xml
   category .../
   category .../
   category .../
   /content
   /entry

No, that isn't one entry in a collection of atom categories, that is one
entry in a collection of *bundles* of atom categories. That's as wrong
headed as trying to squeeze *three* images into the one atom media entry.

If I have three categories in the collection, then they would be in three
individual entries.

 An atom:content with an XML media type MUST have exactly one
 child element, so you can¹t do that. You need to wrap those
 categories in something. The manifest choice is atom:entryŠ

If I have a collection of atom:categories, the atomic unit is one
atom:category. So having a collection where each entry has *one*
atom:category in the atom:content element is what I would be trying to do.

If I wanted to have a collection of _bundles_ of atom:categories, I'd
probably need some foreign element to act as the bundling element (eg.
foo:categories)

 Which just so happens to be a valid root element for
 `application/atom+xml`. Of course, you¹re pulling in an entire
 train of metadata elements at that point, which will probably be
 completely redundant, so whether that is any help I don¹t know.

I don't want that train of metadata. I already have an atom:entry with which
to carry metadata for that content. (Heh, I could even apply atom:categories
to that content, same as any other content ;-)

The last niggling concern is with atom-format: although atom:content can
contain XML, can that be *any* XML data, or does the spec forbid atom+xml
from there? What will the validator do?

e.




Re: examples of merged feeds/feed aggregation?

2005-12-20 Thread Eric Scheid

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.



Re: clarification needed: order of children of atom:entry

2005-10-27 Thread Eric Scheid

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.



Re: Sponsored Links and other link extensions

2005-10-25 Thread Eric Scheid

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 as: here is a link (ooh, look, some alternate href's!)

 If an implementor has to support alternative links explicitly for each type of
 main link, where¹s the difference to having specific relationships for
 alternative links depending on the main link type?
 
good point.

e.




Re: Sponsored Links and other link extensions

2005-10-25 Thread Eric Scheid

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 verbose and you have to fiddle with nesting.
 
 What do you get in return? ³It looks more XMLish²?
 
 
 yes!? We are using xml!

not only that, but if someone wants to write another extension (gasp!), it
would be very easy to fold it in, using native XML methods...

link ..
x:alternate y:attribute=.. ...
z:extension .../
/s:alternate
/link

(not that I can think of any such extensions, but why be a bastard to future
inventors and innovators?)

e.




Re: Sponsored Links and other link extensions

2005-10-25 Thread Eric Scheid

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 and/or location. Lots.

e.



Re: New Link Relations -- Ready to go?

2005-10-24 Thread Eric Scheid

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 link to a table of contents
 feed allowing navigation to e.g. snapshots of non-incremental feeds;
 another link relation for the webring use case if it proves to be needed
 one day).

+1



Re: Sponsored Links and other link extensions

2005-10-24 Thread Eric Scheid

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 the duplicate bandwidth problem again :-(

 If you combine this with the requirement that an inner link with the same
 type and hreflang as the outer link must be bit-for-bit identical, we could
 cover the other use-case of multiple download sources. So far, no new
 elements or attributes necessary.

what about the use case of alternate formats (etc) for the same resource?

 Not sure about the legality.

not legal, since atom:link cannot appear there ie. while atom:link (the
container) can contain foreign markup, atom:link (the embedded) is not
foreign markup.

e.



Re: Sponsored Links and other link extensions

2005-10-24 Thread Eric Scheid

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.




Re: Sponsored Links and other link extensions

2005-10-24 Thread Eric Scheid

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
   href=http://example2.com/file.ogg;
   encl:alternative-to=x-file
   /

-1 ... this is starting to get ugly.


e.



Re: Sponsored Links and other link extensions

2005-10-24 Thread Eric Scheid

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, and while
smart clients do no harm they don't get anything which dumb clients already
get.

With this approach dumb clients do no harm, and smart clients gain benefits
not available to dumb clients. It sets up the right ecological pressures for
the market to evolve in a way which is beneficial.

So while let the market/implementations decide is often persuasive, we
really should at the same time be asking what environment/ecology are we
establishing for this evolution.

e.



Re: Sponsored Links and other link extensions

2005-10-24 Thread Eric Scheid

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 elements and iterating over it.

There's another problem with this:

   @encl:mirrors=http://www2.example.com/file.mp3
http://www3.example.com/file.mp3;

... how do you attach @title to each URI,

for example @title=Blah blah -- European Mirror.

e.




Re: Sponsored Links and other link extensions

2005-10-22 Thread Eric Scheid

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 href=http://example.com/file.mp3;
 x:alternate type=application/ogg href=http://example2.com/file.ogg; /
 /link
 
 (b)
 link rel=enclosure type=audio/mpeg
 href=http://example.com/file.mp3; /
 link rel=enclosure type=application/ogg
 href=http://example2.com/file.ogg; /

With (b), how could you ever then provide multiple distinct enclosures for
an entry. With (b) you're trying to say that the two sound files are the
same thing, just different formats.

For example, I might want to provide a movie file with commentary, and
another movie file without commentary, and a third movie file showing just
the special effects part in slow motion. They are not substitutes for each
other.

With (a), we know the .mp3 and the .ogg are simply different formats of the
same thing. With (b) we don't know either way.

 What I want is a way of indicating that a particular resource is
 available at multiple locations.  I'll use multiple link elements to
 indicate that there are multiple formats.

And some aggregators will treat that as a basket of different enclosures and
try downloading all of them.

 it would be fair to say that any two x:alternate with different @href's but
 equivalent x:md5 are mirrors. That can fit into the model with no other
 modifications :-)
 
 I would argue that the x:md5 for all alternates should be the same as
 the parent link.
 

What about this though:

entry xml:lang=en
  link href=1 rel=enclosure
type=audio/mpeg x:md5=hash1 title=soundtrack
x:alternate href=2 type=audio/mpeg x:md5=hash1/
x:alternate href=3 type=audio/mpeg x:md5=hash1/
x:alternate href=4 type=audio/mpeg x:md5=hash1/
x:alternate href=5 type=application/ogg x:md5=hash2/
x:alternate href=6 type=application/ogg x:md5=hash2/
x:alternate href=7 type=application/ogg x:md5=hash2/
x:alternate href=8 type=audio/wav/
  /link
  link href=9 rel=enclosure type=audio/mpeg title=commentary
x:alternate href=10 type=audio/mpeg hreflang=pt/
  /link
/entry

Here we have an entry with two enclosures. The first enclosure is the
soundtrack, and is available in mp3 from one primary URI and three mirrors,
and also available in .ogg from three mirrors, and for the truly desperate
also available as a .wav file. The second enclosure is a commentary sound
track, but not available in any other formats or from any other mirrors, but
there is a Portuguese translation variant if you (really) want.

e.



Re: New Link Relations -- Ready to go?

2005-10-21 Thread Eric Scheid

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 we're in a moment of grace right now and we could, with a bit of
public advocacy, get 'subscribe' established and supported for one-click
subscription.

 For these two (similar) reasons I think it might be wise to keep
 rel=self in the role that this new rel=subscribe thing is
 supposed to fulfill, and invent a new relationship that can point
 to the canonical location of the archive feed document.

This occurred to me too, but I had my reservations about it.

http://www.imc.org/atom-syntax/mail-archive/msg17284.html

where I wrote:

Fortunately, the link relation 'self' was defined in such a woolly
way we could get away with re-purposing it. A few articles here or
there, a bit of blog chatter, and the arrival of the fabled Developers
Guide and we'd be set.

I'd think this would be favourable to having to come up with a
different pair of relations, like

'self'   = what you subscribe to,
   may not look anything like the chunk in front of you

'this-chunk' = link to what you are looking at,
   not to be confused with 'self'

e.



Re: Application for addition to Atom Registry of Link Relations

2005-10-21 Thread Eric Scheid

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
informational content has been published under multiple copright
licenses.  In such instances, each of the linked licenses is
considered to be mutually exclusive of the others.

but the second bit of text suggests that the following is allowable:

link rel=license href=pay-me-for-commercial-use /
link rel=license href=barter-for-commercial-use /
link rel=license href=free-for-non-commercial-use /

which is a situation which should be allowable (IMHO), and so the
restriction should be removed:

o  atom:entry, atom:feed and atom:source elements MUST NOT contain
   more than one 'license' link relation with the same
   combination of type and hreflang attribute values.

e.



Re: New Link Relations -- Ready to go?

2005-10-20 Thread Eric Scheid

+1 to all



Re: Feed History / Protocol overlap

2005-10-19 Thread Eric Scheid


 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
 distinction IMHO. 
 
 You said that to me about next and previous for app:collection when I
 requested the value 'next' be changed to 'previous' to be  consistent
 with the notion of elements existing earlier in time.

 What's different here?

Nothing. 

I should have been more clear back then that I was +1 on 'previous'... my
point was directed at Joe (not you), and that his line of argument (in
favour of 'next') was not persuasive and so if he wanted 'next' then he'd
better try another line of argument.

As then as now, I'm still +1 on 'previous' for going backwards.

e.



Re: New Link Relations? [was: Feed History -04]

2005-10-18 Thread Eric Scheid

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.



Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-18 Thread Eric Scheid

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 reference another feed document where each
 entry describes an archive:

The word 'archives' is too general though. May I suggest @rel=history
instead?

Otherwise, +1

e.



Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

2005-10-18 Thread Eric Scheid

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 documents, paging is navigation from one to the other, following
 the sort order.

... and the subset of entries which are on page 1 sorted by one axis would
be very unlikely to be on page 1 when sorted by some other axis.

d'oh!

 If you want to provide the exact same entries sorted (thus paged)
 differently, then that's another feed.

unless of course each feed document contains only one entry each ;-)

e.



Re: Feed History / Protocol overlap

2005-10-18 Thread Eric Scheid

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.



Re: Feed History / Protocol overlap

2005-10-18 Thread Eric Scheid

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 forward-chronological series of feeds?

e.



Re: Feed History -04

2005-10-17 Thread Eric Scheid

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
 the updated time gets older, then the client can understand these
 entries are from an earlier time. If when following the next link the
 updated time stays the same, then the client can assume this is just
 more of the same collection from the previous point in time (unordered
 collection). Just a thought...

Won't work -- older date-paged archives may have an entry updated anytime in
the future, and thus not only does that entry get a more recent atom:updated
than any entries intervening then and now, but the feed itself will also get
a more recent atom:updated.

e.



Re: Feed History -04

2005-10-17 Thread Eric Scheid

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 the use of
 'first/next/prev/last' with chapters or sections rendered in HTML.
 
 I'm still not exactly sure which of the two options you're in favour of. This
 is the reason why the point is being debated - it's not immediately obvious
 which way is most consistent with usage elsewhere. Nottingham or Pilgrim?
 

hmmm ... I did say Consider the use of 'first/next/prev/last' with chapters
or sections rendered in HTML... Chapter #1 comes first, followed by chapter
#2, and you go from chapter #1 through to chapter #nnn via 'next'.

Think too of Pepys' Diary. What would you consider the 'first' entry? Would
the 'first' entry be 1st January 1660, or would it be 16th October 1662?
Note well though that sometime tomorrow the latter point would be neither
'first' or 'last' because there would be a new entry for the 17th October
1662 (and yet another one the day after).

 2. Are next and prev both needed in the spec if we only require one of them
 to reconstruct the full history?
 
 Knowing that the most recently published archive won't likely remain the most
 recently published archive, there will be use cases where it's better to
 reconstruct the full history by starting at the one end which is fixed. Not
 much sense starting at the other end which is constandly shifting.
 
 The way I understand it, both sides are fixed as soon as there is at least one
 archive. At the one end you have the oldest archive. At the other end you have
 the current syndication document (to which the end-user would subscribe). Both
 URIs are fixed. 

What I mean by fixed is that it doesn't move or change as the set grows.
Adding one onto the end and resetting where 'last' points to means that
'last' is *not* fixed.

What you mean is that as soon as there is at least one archive then both
ends are *established*. One end is fixed, and the other will grow.

 5. Is the issue of whether a feed is incremental or not (the fh:incremental
 element) relevant to this proposal?
 
 non-incremental feeds wouldn't be paged, by definition, would they?
 
 This has been debated. There have been those who have expressed an interest in
 having next and prev links traverse an archive of old non-incremental feeds.
 Say you have a feed with the top 10 books for this month. The next link (or
 prev link, depending on your preference) would point to the archive document
 with the top 10 books from last month.

That makes sense.

 Personally I think that is an issue that should be argued and subsequently
 specified in a separate proposal on the use of non-incremental feeds. Just
 make sure the history spec is open enough to allow for either possibility once
 it is decided.

I agree. So .. the issue of (not-)incremental is orthogonal to feed history
then.

e.



Re: Feed History -04

2005-10-17 Thread Eric Scheid

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
 'first/next/prev/last' with chapters or sections rendered in HTML.
 
 ...so do you follow forward through time or backward?  Is the  starting
 current position now or the the beginning of time?   Especially if we're
 talking about history, following backward makes  as much sense as following
 forward.

You can start wherever you want, but the @rel='first' archive is the
archive which contains the first entry that ever existed. Why would the
@rel='first' archive contain the last entry created, that makes no sense.

If you want to go backwards in time, then the next archive would be found
by following the @rel='prev' link .. because you are going backwards!

 I prefer next to go back in time (if temporally ordered--from the  most
 current chunk to the next most current chunk) or to less  significant pages
 (in things like search results).  But I'll probably  have to stop and think
 what next means in temporally ordered feeds  from time to time since it'd be
 the reverse of temporal order.

You're also likely to get confused when comparing Atom archives against
their HTML versions ... because in the HTML world the '@rel=first' page is
conventionally the oldest page, and the @rel='next' page traverses forward
in time.

 But what's first?  It'd be the top results in a search feed, but
 would it be the start of time or the start from the present (before
 possibly travelling backward through time) in a temporally ordered
 feed?  Making it the start of time would prevent it from matching up
 well with how significance ordered feeds match up (ie. does start
 point to the thing you'd most likely want to see if you subscribed to
 the feed?)  If we're not careful, we'll be traversing out of first
 through prev and last through next!

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. Remember that by the
time you've read back to the initial posting there would likely now be even
more entries into this thread, so where would you then read them from ...
where you started and going forward in time, or would you jump to the most
recent and then read backwards until you hit a message you already read?

So, would you read the messages in this order:

7,6,5,4,3,2,1,8,9,10,11,12,13,14

or...

7,6,5,4,3,2,1,11,10,9,8,13,12,14

or...

1,2,3,4,5,6,7,8,9,10,11,12,13,14

I know which way I'd prefer to read stuff.

e.



Re: Feed History -04

2005-10-17 Thread Eric Scheid

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 looking at an historical chunk, you would still
need some link to where you might subscribe to that feed.

So, if polymorphic, you'd have in the current living chunk a link of 'self'
to subscribe to, but in a historical chunk you'd need to ignore the 'self'
link and follow the 'subscribe' link instead.

If not polymorphic, in the current living chunk you'd have a 'subscribe'
link, and in a historical chunk you'd have a 'subscribe' link. They would
both mean the same thing, and have the same value. In the historical chunk
the 'self' link would be different from the 'subscribe' link (pointing at
the historical chunk, of course), but in the current living chunk they could
very well have the same value ... or not...

The or not case is best exemplified by the nature.com feed links. If you
want to subscribe to Nature Medicine, you'd use this URI ...

http://www.nature.com/nm/current_issue/rss/

... but if you were to attempt to retrieve that URI today you would find
yourself redirected to ...

http://www.nature.com/nm/journal/v11/n10/rss.rdf

... where, if were atom, you might find a 'self' link pointing to that
second URI, not the first.

The nature.com feeds are, btw, a rather good real-life example of
non-incremental feeds.

e.



Re: Feed History -04

2005-10-17 Thread Eric Scheid

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 Technically, they wouldn't necessarily be closed sets. Tim Bray,
search god that he is, has explained in some blog post somewhere that the
smart thing to do is simply find the first hundred or so results, sort them,
and only when the user asks for more pages to bother going off and finding
more results to add to the collection. It's complicated, I think I
understood it for all of 10 seconds after I finished reading it, and it only
really applies to searching massive collections ... searches in more finite
collections would be, could be, completely closed sets. /geeking

e.



Re: Feed History -04

2005-10-17 Thread Eric Scheid

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. Remember that by the
 time you've read back to the initial posting there would likely now be even
 more entries into this thread, so where would you then read them from ...
 where you started and going forward in time, or would you jump to the most
 recent and then read backwards until you hit a message you already read?
 
 This makes perfect sense if you're a human reading messages, but now try and
 understand it from the point of view of a computer program (an Atom
 processor). The computer doesn't care which messages came first.
 

Yes, the _computer_ does *not* care. So why should it's preference trump the
human reader?

I imagine a future where a client application would offer up feed documents
rendered all pretty, and offer up any links to other feed documents as links
the client application will itslef render rather than passing them to a HTML
browser. Thus, a Feed Browser in the same sense as a HTML Browser. Do you
want to explain to future users why the next link gives them last weeks
news instead of next weeks news?

 It's not going to try and read the messages and make sense of them. It just
 wants to retrieve all the documents in the most efficient way possible.

Do things efficiently then. Remember though that the computer does *not*
care if the token is 'next' or 'prev' or even 'foobar'. Does *not* care.

 First off is has to start with the most recent document since that's what the
 user is going to subscribe to. From there, the most sensible thing to do would
 be to keep following links back in time to older and older archives until it
 has retrieved all of them or (if this is a feed that has been downloaded
 before) until it reaches an archive that it has previously retrieved.

Did you say back in time? Your explanation is riddled with references to
going backwards .. the aggregator/developer frame of reference is going
backwards, so of course the next object would be the one marked as being
prior to the one your are currently on. That is, the next feed to process is
the one marked @rel='prev'.

Depending on what meta-data is available, and which axis you wish to
traverse, and in which direction, then the link to the object you wish to
retrieve after processing the current one could be next, prev, hotter,
colder, or foobar. The usage of the word next in describing the
sequence of actions is entirely dependent on the purpose of those actions,
and quite possibly completely detached from the meaning of the content being
processed. 

The @rel='next' and @rel='prev' links however are part and parcel of the
content. They describe the content. They are provided by the content
publisher. They don't describe some third party's desired course of action.

 I don't dispute that you have valid reason for thinking that forwards in time
 is the way to go, but please don't assume those of us that think the opposite
 are necessarily insane.

But that would take all the fun out of things ;-)

e.



Re: New Link Relations? [was: Feed History -04]

2005-10-17 Thread Eric Scheid

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 equivalent to the containing element.

thus a link with @rel='self' in the feed element would link to that
archive feed document. Similarly, a link with @rel='self' in the entry
element would link to a resource document of that particular entry.

Thus (in context of feed)

'self'  = identifies a resource equivalent to this feed
'subscribe' = identifies the resource to subscribe to

The same holds true for archive feeds and the current sliding window chunk,
which makes life easier.

e.



Re: Feed History -04

2005-10-14 Thread Eric Scheid

On 15/10/05 12:48 AM, Mark Nottingham [EMAIL PROTECTED] wrote:

 Also -- I'd think that the last link is already covered by self,
 no? If not, there's some pretty serious confusion about what 'self'
 means.

What if a magazine publishes articles only once per month, each month's
entries are all in one feed document, each feed document with unique URIs,
and the public 'self' URI simply redirects to the last feed document.


That is:

http://example.com/monthly/current.atom

redirects to 

http://example.com/monthly/2005-10.atom

Of course you can find the 'last' archive via the 'self' URI, but that
doesn't make them the same thing. If you were paging through using 'next',
how would you know you've reached the 'last' ... apart from running out of
'next' links, and apart from separately retrieving the 'self' URI and noting
the eventual URI handed back so you can compare against the one in 'last'.

Why would anyone want to know the 'last' link? One use case is that one
could take note of the 'last' URI, and then later find out what the 'last'
URI now is ... and if they are different then obviously more has been added
and it's time to go fetch.

e.



Re: Feed History -04

2005-10-14 Thread Eric Scheid

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 anchored, while the 'last' end would shift as
more is added.

e.



Re: more than one content element?

2005-10-13 Thread Eric Scheid

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 cope with
the possibility, first detecting that there are multiple atom:content
elements, and then having to either choose one of the formats they support
or providing mechanisms for the user to select.

It would have been handy for a recent use case: in Switzerland, govt
announcements need to be made in three languages, simultaneously, and
without favour to any one language.

e.



Re: Feed History -04

2005-10-13 Thread Eric Scheid

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 need to define what 'first' means though?  I recall a dissenting
opinion on the wiki that the 'first' entry could be at either end of the
list, which could surprise some.

e.



Re: Feed History -04

2005-10-13 Thread Eric Scheid

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
start. In the context of paging link relations (first/next/prev/last) I
would've thought that 'first' and 'last' are boundaries, and only the 'last'
boundary would shift over time as more is added.

e.



Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

2005-10-09 Thread Eric Scheid

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 better for this semantic. Unlike
atom:updated, it can be hold a future value, IIRC.

e.



Re: ACE - Atom Common Extensions Namespace

2005-10-02 Thread Eric Scheid

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 standardized extensions can be grouped.  I've
 written an initial draft of the concept but before I submit it as an
 Internet Draft, I'd like to get some feedback from the group.  Please
 review the attached and let me know what you think.

Do you want to start it off as an empty container, or might it be strategic
to submit it with a number of extensions mentioned by reference. If the
latter, it would serve a bootstrapping purpose for developers new to Atom.

A bit like that page for RSS which enumerates a collection of extensions.



What about mustIgnore/mustUnderstand? An extension sharing the ACE ns can't
require mU, right?

e.



Re: FYI: Updated Index draft

2005-09-21 Thread Eric Scheid

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) bbc.co.uk order their news items in some sensible
manner?

Today, they have a couple of important stories, they indicate those entries
are rank #1, #2. Tomorrow, they have more news, but not more important than
yesterday's big news. The day after they have a new big story, it should be
rank #1. The #1 and #2 stories from two days ago have fallen off the bottom
of the feed. 

The only way out of this conundrum is that bbc.co.uk will have to update the
original #1 and #2 stories and re-rank them as much lower. If they re-rank
them as #46 and #47 then they will need to re-rank any previous entry at
those ranks to lower positions, and similarly for any other entries with
ranks which get pushed down. Eventually the entire history of the feed needs
to be re-ranked.

Unless entries can be marked as having no rank. Can they?

e.



Re: FYI: Updated Index draft

2005-09-21 Thread Eric Scheid

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 the item, and thus a
rank#1 item would appear near the top of the list, and then slowly drop
away.

You also get to know what the original ranking for an item is.

e.



Re: FYI: Updated Index draft

2005-09-20 Thread Eric Scheid

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 diff+Feed method of partial feed
retrieval?

e.



Arr! Avast me hearties!

2005-09-19 Thread Eric Scheid

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 magic switch and all their content
is now appearing in Pirate Speak (via the magic of output filters, and
barrels of rum).

This includes messages posted before official pirate day.

Sometime in the near future I expect they'll sober up, see the day has
passed, and unflip the magic Pirate Speak switch.

And all the subscriptions will again be presented in teh orginal spellig
wonder.

So ... ObAtom ... would recommended practice be to emit the garbled
enunciations inline, with no change to atom:updated, and if there is any
version tracking or modified dates present to also not update those? Make it
look like some blurred illusion, fading from reality like a bad dream the
next day faster than our rum soaked hangovers?

e.



Re: FYI: Updated Index draft

2005-09-15 Thread Eric Scheid

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.



Re: Structured Publishing -- Joe Reger shows the way...

2005-09-11 Thread Eric Scheid

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
 the content or the metadata. Where should the metadata go?
 
 Hmm. I think it¹s not metadata that we¹re talking about here,
 it¹s data. The location etc aren¹t a description of your weblog
 entry, they¹re a description of a place. So is your article.
 
 In other words, your article is ³meta²data about the cool bar.
 So it goes inside the RDF that is the entry¹s content.

I was thinking the opposite. The article goes into content as text/xhtml,
and the RDF goes into the entry as extensions.

 Now, that¹s not going to be accessible to clients who don¹t know
 look in the right place in the graph.

Again, all the RDF extensions won't be accessible to clients that don't know
where to look, but the article content will be available, because it's one
of the baseline formats.

 So you put a copy of the article in your atom:summary, because it
 summarizes the full thing available in the RDF payload.

Not if it's a long article, please.

e.




Re: Question regarding specification 4.1.1

2005-09-07 Thread Eric Scheid

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 (and only one) atom:id element but can
 have 0:n atom:entry elements.

The atom:id element as an *immediate* child of atom:feed is the ID for the
feed, while the atom:id element found as children of atom:entry elements are
the ID's of their respective atom:entry. Completely different things.

 If multiple atom:entry elements with the same atom:id value appear in
 an Atom Feed Document, they represent the same entry.

Consider this (abbreviated) example:

feed
idsome-id-for-the-feed/id
...
entry
idid-for-entry-1/id
...
/entry
entry
idid-for-entry-2/id
updated2005-09-06T01:00:00Z/updated
...
/entry
entry
idid-for-entry-2/id
updated2005-09-06T01:05:00Z/updated
...
/entry
/feed

This feed contains three atom:entry elements, two of which are actually
separate representations of the same source entry, one at 1.00 AM, and one
from five minutes later.

In practice you probably won't see a mix like the above.

e.



Re: Top 10 and other lists should be entries, not feeds.

2005-08-30 Thread Eric Scheid

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. And then
update chapter 2.

Sometimes there are good reasons for this, strangely enough.

Leaving aside completely the idea of publishing a chunk, followed by more
chunks, and *then* re-arranging them into some semblance of logical order
once they know what content they have.

e.



Re: Top 10 and other lists should be entries, not feeds.

2005-08-30 Thread Eric Scheid

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 cases are also a good example of some feeds which shouldn't
be devoured by robots.

e.



  1   2   3   4   >