Re: versioning extension?
On Sep 11, 2006, at 4:39 PM, Jan Algermissen wrote: If I am not completely wrong, versioning is definitely an issue if you want to employ Atom in beyond-blogging contexts. Most people that deal with collections of items are definitely interested in keeping track of the former versions of the items. Versioning is an issue in almost *every* application. What is so bad about it? In my experience, the semantics of "versioning" are so tightly bound to particular applications that it's really hard to find common threads. You saw that happen here when we were arguing about atom:updated, Asbjørn had a particular vision of versions that seemed obvious to him and unreasonable to others. When a textbook publisher and a medical-instrument embedded-software maker and a wiki implementor use the word "version", I guarantee you they mean entirely different and wildly incompatible things. Good luck; you'll need it. -Tim
Re: versioning extension?
Le 12 sept. 06 à 08:39, Jan Algermissen a écrit : Umm...am I missing something? Is it that bad? What I am basically aiming at is a common means to relate entries to each other to indicate one is a version of the other or to link from an entry to a feed that consists of versions of that entry, If I am not completely wrong, versioning is definitely an issue if you want to employ Atom in beyond-blogging contexts. Most people that deal with collections of items are definitely interested in keeping track of the former versions of the items. Are you talking about threading? Why not putting it outside of Atom and use the power of links for threading. Similar discussion but for comments happened on microformats ML. So IMHO, it is slightly off-topic, in the sense you could achieve it by an application built on top of Atom without touching Atom AND Tim Bray could come back in the room :p From the microformats ML Le 12 sept. 06 à 08:35, Karl Dubost a écrit : Hi Steph, Le 12 sept. 06 à 07:17, Stephanie Booth (bunny) a écrit : A while back somebody showed me a blog marked up with hatom. That person used hatom on the comments too (on the single post page) -- that meant two hfeeds: one containing only the post, and another one with the comments. Does this way of using hatom on comments make sense to you? I noticed that neither K2 nor Sandbox wordpress themes do this. Completely logical. Each individual comment is nothing more than a weblog post. The only technical difference is that it is not made on another weblog, but directly on the weblog of the person. Each individual comment is structured like a weblog post. It has (required) - an id, the URI of the comment - a title, often the same than the original weblog post, sometimes a different (see SPIP) - a date when it has been done (updated) It has (recommended) - often an author - content (core text of the comment) - link (the URI of the Weblog original post we are commenting on) It just miss a summary, but that is not mandatory in Atom either. IMHO, it should be an individual hatom entry for each comment, The way everything is aggregated and organized has a full feed is another debate. The date and link should help to create a pseudo thread. It could be a full thread like in SPIP when the commenter has the possibility to reply to a specific comment in this case the link becomes the URI of the specific comment. -- 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: versioning extension?
On 12.09.2006, at 01:23, Tim Bray wrote: On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote: is anybody working on (or planning to work on) a versioning extension for Atom? I am about to use Atom in two (considerably different) projects that require versioning and would be happy to join forces and contribute real (enterprise-)world use cases. (Note: not 'enterprisey' use cases :-) Eeek! Flee for your lives! *runs for the nearest exit* -Tim Umm...am I missing something? Is it that bad? What I am basically aiming at is a common means to relate entries to each other to indicate one is a version of the other or to link from an entry to a feed that consists of versions of that entry, If I am not completely wrong, versioning is definitely an issue if you want to employ Atom in beyond-blogging contexts. Most people that deal with collections of items are definitely interested in keeping track of the former versions of the items. What is so bad about it? Jan
Re: versioning extension?
On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote: is anybody working on (or planning to work on) a versioning extension for Atom? I am about to use Atom in two (considerably different) projects that require versioning and would be happy to join forces and contribute real (enterprise-)world use cases. (Note: not 'enterprisey' use cases :-) Eeek! Flee for your lives! *runs for the nearest exit* -Tim
versioning extension?
Hi, is anybody working on (or planning to work on) a versioning extension for Atom? I am about to use Atom in two (considerably different) projects that require versioning and would be happy to join forces and contribute real (enterprise-)world use cases. (Note: not 'enterprisey' use cases :-) Jan
Re: Private extensions and relation to atom elements
On Mon, Sep 11, 2006 at 08:36:02AM -0700, Tim Bray wrote: > let's assume myns: is declared. Then why not > > icon-uri Apologies to all - this is what we tried first, but there must have been a typo or something, because the feed validator started shouting at us. I've just checked again, and all is well. Cheers, James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Private extensions and relation to atom elements
On Sep 11, 2006, at 7:45 AM, James Aylett wrote: Feed Validator gets upset with extension attributes - is it wrong? Be specific, please? -Tim
Re: Private extensions and relation to atom elements
On Sep 11, 2006, at 4:27 AM, James Aylett wrote: We've run across a situation where we want to annotate an atom:icon with a title. Currently we're doing the following, as something that Feed Validator is happy with, but doesn't feel right: -- uri:to/icon My icon title let's assume myns: is declared. Then why not icon-uri -Tim
Re: Private extensions and relation to atom elements
On Mon, Sep 11, 2006 at 08:09:27AM -0700, James M Snell wrote:
> atom:icon is defined as:
>
>atomIcon = element atom:icon {
> atomCommonAttributes,
> (atomUri)
>}
>
> atomCommonAttributes is defined as:
>
>atomCommonAttributes =
> attribute xml:base { atomUri }?,
> attribute xml:lang { atomLanguageTag }?,
> undefinedAttribute*
Hmm, I'd misunderstood what undefinedAttribute meant. Or, more likely,
missed it entirely. Thanks :)
> The Validator should be ignoring any extensions (including attributes)
> it is not familiar with so yes, I would say that it's wrong if its
> returning an error. A warning would be appropriate tho given that not
> all implementations will be capable of making use of extension attributes.
Should the validator have different levels of warning? For instance,
it warns you if you have some iTunes extensions but not others; it
warns you if your RSS uses dates in a strange format that some readers
might not be able to parse; it should warn here. These are all
different: specific application may have problems; general
applications may have problems with a core feature; general
applications may ignore an extension.
(This isn't really the right forum for this, so apologies.)
> One additional point, be sure to clearly define whether or not your
> title attribute value should be interpreted as plain text or escaped
> markup (preferably the former).
Well, it's a private extension, so in practice you're not going to
know if we define it or not :-)
But yeah, point taken and I'll make sure it gets added to our spec
internally.
James
--
/--\
James Aylett xapian.org
[EMAIL PROTECTED] uncertaintydivision.org
Re: Private extensions and relation to atom elements
atom:icon is defined as:
atomIcon = element atom:icon {
atomCommonAttributes,
(atomUri)
}
atomCommonAttributes is defined as:
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
The Validator should be ignoring any extensions (including attributes)
it is not familiar with so yes, I would say that it's wrong if its
returning an error. A warning would be appropriate tho given that not
all implementations will be capable of making use of extension attributes.
One additional point, be sure to clearly define whether or not your
title attribute value should be interpreted as plain text or escaped
markup (preferably the former).
- James
James Aylett wrote:
> On Mon, Sep 11, 2006 at 07:27:27AM -0700, James M Snell wrote:
>
>> Using extension attributes is a perfectly legitimate solution. The one
>> drawback is that not all implementations will support 'em.
>
> That's not a problem, to be honest - we have (amongst other things) a
> Flash 'player' for the atom feeds involved, and some clients want a
> title alongside the feed icon and/or logo.
>
> Feed Validator gets upset with extension attributes - is it wrong?
>
> James
>
Re: Private extensions and relation to atom elements
On Mon, Sep 11, 2006 at 07:27:27AM -0700, James M Snell wrote: > Using extension attributes is a perfectly legitimate solution. The one > drawback is that not all implementations will support 'em. That's not a problem, to be honest - we have (amongst other things) a Flash 'player' for the atom feeds involved, and some clients want a title alongside the feed icon and/or logo. Feed Validator gets upset with extension attributes - is it wrong? James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: Private extensions and relation to atom elements
Using extension attributes is a perfectly legitimate solution. The one drawback is that not all implementations will support 'em. - James James Aylett wrote: > We've run across a situation where we want to annotate an atom:icon > with a title. Currently we're doing the following, as something that > Feed Validator is happy with, but doesn't feel right: > > -- > uri:to/icon > My icon > title > -- > > It doesn't express the relationship directly. The way that would be > most natural in XML doesn't seem to be allowed (because we don't have > extension attributes): > > -- > uri:to/icon > -- > > and all other ways I can think of involve extension elements in the > wrong place. > > Anyone have another suggestion on how to approach this? Or would we be > better off adding our own which we can decorate with > titles, languages and whatever to our heart's content, even though > it's redundant to some extent? > > James >
Re: atom license extension (Re: [cc-tab] *important* heads up)
I talked with Lisa a bit about this next week. I'll be working on iterating the draft based on this conversation and will request another last call once it's ready to go. - James Thomas Roessler wrote: > On 2006-09-08 08:21:59 -0700, James M Snell wrote: > >> I think the discussion around this has been absolutely excellent. >> Lots of very good information and perspectives. At this point I >> need to stew over things for a few days and think about how to >> proceed with the extension. > > The last call for this spec is ending today... I'm wondering a bit > what the next step (if any) between you and Lisa (as the shepherding > AD) needs to be in order to make sure that this goes as you intend > it to go. >
Private extensions and relation to atom elements
We've run across a situation where we want to annotate an atom:icon with a title. Currently we're doing the following, as something that Feed Validator is happy with, but doesn't feel right: -- uri:to/icon My icon title -- It doesn't express the relationship directly. The way that would be most natural in XML doesn't seem to be allowed (because we don't have extension attributes): -- uri:to/icon -- and all other ways I can think of involve extension elements in the wrong place. Anyone have another suggestion on how to approach this? Or would we be better off adding our own which we can decorate with titles, languages and whatever to our heart's content, even though it's redundant to some extent? James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: atom license extension (Re: [cc-tab] *important* heads up)
On 2006-09-08 08:21:59 -0700, James M Snell wrote: > I think the discussion around this has been absolutely excellent. > Lots of very good information and perspectives. At this point I > need to stew over things for a few days and think about how to > proceed with the extension. The last call for this spec is ending today... I'm wondering a bit what the next step (if any) between you and Lisa (as the shepherding AD) needs to be in order to make sure that this goes as you intend it to go. -- Thomas Roessler <[EMAIL PROTECTED]>
