Re: License Draft: Tortured text re obligations...
Le 17 déc. 2006 à 11:24, Bob Wyman a écrit : There is, I think a bit of tortured text in James Snell's otherwise useful License ID[1]. 1.3. Terminology bob wyman [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed- license-10.txt +1 -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Inheritance of license grants by entries in a feed
Sunday, December 17, 2006, 1:55:39 AM, Bob Wyman wrote: > 2.3. Inherited Licenses > The license on a feed MAY be inherited by entries. James, I'm not sure exactly what you are trying to achieve with the inheritance rule for licenses, but I think that it could do with the term "feed" being more accurately specified. Whilst it would be very useful for extensions to be able to support inheritance rules like the ones that Atom specifies for atom:author and atom:rights, which cause properties applied to a "feed document" to inherit to the entries declared within the "feed document"; there is nothing in Atom's specification of extensions elements that supports this short-hand notation, and attempting to emulate this behaviour in an extension will cause real-world implementations of feed stores to incorrectly assign, or not assign, licenses to the wrong entries. Simply because Atom implementations tend to give entries and feeds seperate life-cycles, and implementations that maintain a feed-state over multiple pollings of a feed are unlikely to associate each entry with the set of feed document metadata from each of the documents that it occurred in. Eg, if you store a feed in an implementation such as Microsoft's Feed Engine, only a single set of feed extensions will be associated with the feed. This will mean that if you change the license in the feed document when a feed is subsequently polled, intending it only to apply to the entries within that new feed document, you will effectively retroactively apply the license to the old entries too. Atom, unfortunately, doesn't have a way of indicating that an extension applies at "feed document"-level and MUST be processed at the feed document parsing stage. What you can do however, is to specify that feed licenses apply to the "feed", and inherit to the entries in the feed. This behaviour doesn't require implementations to be psychic and guess that an unknown extension needs to be processed at the document parsing stage. It means that the license applies to all entries in that feed, not just ones in that specific feed document. This is probably reasonable behaviour for licenses anyway. This might be your intention, but I'm not clear from the draft. -- Dave
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/16/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: Extending the Atom envelope is a strategy of last resort. +1 It is important to remember that not all processors of Atom data will know what to do with unexpected metadata in the envelope. Thus, unexpected envelope fields will often simply be stripped off and thrown to the bit bucket. If you want data to stay with your "content," it is best to put it in the ... Sometimes, it may be appropriate to extend the envelope, however, one should not do so without a really compelling case. Envelope extensions typically require "fetching time" or database structure modifications in consuming applications if those extensions are to be supported. This is because many feed consumers have distinct fields in their databases or internal structures for each of the envelope elements and then just have a single field for content. Also, the code for manipulating envelope fields is usually distinctly different from the code used to manipulate and process . So, if you create a new envelope field, you require a great deal of code to be modified for that field to be supported. On the other hand, if something can be slipped into you'll see it being stored immediately and have the opportunity for downstream consumers (display routines, etc.) to provide support for the additional data. (For instance, you might write a GreaseMonkey script to do interesting things with stuff encoded in even though the "backend" of the application knows nothing about it.) My personal feeling is that many of the proposals (but not all) for envelope extensions are derived from what I consider to be unfortunate precedent set in the RSS world where all sorts of random stuff has been pushed into the envelope since in RSS the field is so under-specified that it isn't really possible to think of it as something which can be structured. Fortunately, the field has moved forward since legacy RSS was defined and we've got better methods that can be used with Atom. There are undoubtedly still things that might go in the envelope, but not as many as some folk might think. bob wyman
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Dec 17, 2006, at 10:13 AM, James M Snell wrote: Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. (Sorry if this has already been said or not on the point, but I cannot read through the thread right now). - The server is free to 'mess' with the PUTed data at will before doing the update; so it can strip out whatever it wants. - Clients should do a GET before doing a PUT so they get some chance to see what the sever actually handles Jan - James Eric Scheid wrote: 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
James M Snell schrieb: Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. ... Again: WebDAV doesn't redefine PUT, so the situation is exactly the same. (Unless you were referring to PROPFIND/PROPPATCH). Best regards, Julian
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. - James Eric Scheid wrote: > 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
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.
