Re: More while we're waiting discussion
* Antone Roundy [EMAIL PROTECTED] [2005-07-13 04:20]: If atom:link is intended to be dereferencable, then clearly, any solution that takes a value from atom:id and puts it into atom:link/@href has a strike against it since any feed that uses non-dereferencable atom:ids would either have to violate the spirit of atom:link to participate in the feature, or would have to invent a competing solution. If atom:link is indeed intended to be dereferencable, then my proposition is bunk and we need an extension element. Even if the atom:id elements in question carried dereferncable URIs, and thus could meaningfully be put into atom:link elements, that is beside the point. The letter of the spec does not mandate dereferancability right now. On whether this is intentional or an oversight, I await judgement from the WG. Obviously, my own vote is that it’s fine as is: I see no reason that dictates that atom:link must point to a concrete Web resource, rather than just an abstract one – neither conceptually/semantically nor in terms of consequences for implementation of Atom generators and consumers. OTOH, if the WG thinks the spec is meant to be stricter than the letter of the current document, that might be a minor spec bug that should be fixed in the -10 draft. (I’m not entirely clear where the minor/major change threshold is at this stage in the process, and if a fix to this aspect would violate it. The wording would only require trivial additions; but the consequences of the change might be considered too major. Unless maybe it’s argued that this was what the spec said all along, and this change therefore is just clarification? I don’t know. Colour me lost.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: More while we're waiting discussion
* Antone Roundy [EMAIL PROTECTED] [2005-07-13 07:05]: Automating feed subscriptions isn't something that should be done too lightly[1]. The default behavior for an aggregator should be NOT to do this, and aggregators should give the user the opportunity to control this feature on a feed-by-feed basis. True, but this doesn’t detract from my argument that we need to be able to signify a tighter relationship than just “related.” An aggregator might want to offer different UI for comment feeds, in contrast to merely “related” feeds. Automatic polling of comment feeds is just one possible behaviour that differentiates the two. Another might be that the aggregator asks the user on subscription whether he/she also wants to poll the comment feed, but draws no particular attention to “related” feeds, and merely shows them on a feed details pane or some such. But the basic issue remains one and the same: the aggregator must somehow be able to tell that some of the linked feeds are highly relevant, whereas others are merely of tangential interest. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: More while we're waiting discussion
Tuesday, July 12, 2005, 12:29:58 AM, James M Snell wrote:
The third is a non-RDF adaptation of the Creative Commons RSS 1.0 Module
that uses the Atom link element and provides a machine readable license
for entries and feeds. It is described @
http://www.snellspace.com/wp/?p=184.
feed
link rel=license
href=http://www.creativecommons.org/licenses/by-nc/1.0;
xmlns:lic=...
lic:permits{URI}/lic:permits
lic:requires{URI}/lic:requires
/link
/feed
I might be on my own here, but I would advise against extending the
link element in this way. I'd say that it is better to use a
Structured Extension Element. The section 6.4 Metadata Elements,
(particularly Simple Extension Elements, though that might not work in
well in this case), are designed so that metadata can be added to
entries without requiring every step in the chain to be upgraded, from
the publishing client, to the XML processor and database of the server
and aggregator.
Because the content of atom:link is undefined, there is a risk that
some implementations, particularly Atom server implementations
accepting entries from a publishing client, might just drop the
contents of the element.
--
Dave
Re: More while we're waiting discussion
* James M Snell [EMAIL PROTECTED] [2005-07-13 06:40]: Maybe “companion?” I don’t know if I like that term, but it’s the best single-word description I can think of off the top of my head. I think we could just as easily attach the you really should auto-subscribe semantic to @rel=related @type=application/atom+xml without incurring any need for coming up with a new link type. That hinges on our respective interpretations of “related.” Is it expected that feeds will link to “related” feeds which are *not* tightly associated with the feed in question? Does there need to be a way for them to do that? If so, then it follows that “related” is the wrong vehicle for this purpose. My opinion is yes, and yes, and hence that is is the wrong vehicle, which leads me to argue for another relationship type. On a conceptual level more-specific is better, but on a practical level, a new @rel label doesn't seem to buy us enough benefit to justify requiring developers to implement support for it. @rel=related feeds can simply be handled differently than other @rel=related stuff. Hmm. The argument is good, but the premise mistaken. Developers will first and foremost have to support the concept of “highly relevant related feed that should probably be polled in addition.” It doesn’t matter what relationship type that’s tied to – it’s implementing the behaviour that takes the bulk of the work. And this behaviour is not in the core spec to begin with, so an implementor who has chosen to implement it has done so consciously enough that they will know about a new relationship type required for it, and will not be deterred by it. The choice of relationship to tie this behaviour to is but a trivial detail that boils down to comparing to a different string literal in one or at best three or four locations in the codebase. Special-casing [EMAIL PROTECTED]'related' and @type='application/atom+xml'] does not seem to be any simpler to implement than keeping an eye out for @rel='companion'. So by all I can tell, overloading “related” for this purpose only muddies the waters semantically such that loosely related extraneous feeds cannot be distinguished from highly relevant ones – without offering any actaul simplicity at all in return. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: More while we're waiting discussion
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-13 08:11]: Obviously, my own vote is that it’s fine as is: I see no reason that dictates that atom:link must point to a concrete Web resource, rather than just an abstract one – neither conceptually/semantically nor in terms of consequences for implementation of Atom generators and consumers. I should clarify that I defer this to the particular relationship type. In an atom:[EMAIL PROTECTED]'alternate'], I do absolutely expect the @href to be dereferencable. What I don’t see any reason for is to mandate that @href must always be dereferencable, regardless of whether the semantics of the type in @rel would require that or not. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: More while we're waiting discussion
* David Powell [EMAIL PROTECTED] [2005-07-13 08:45]: Because the content of atom:link is undefined, there is a risk that some implementations, particularly Atom server implementations accepting entries from a publishing client, might just drop the contents of the element. We had a discussion recently about this very aspect of the spec, which concluded that there is no reason that extension elements would be disallowed inside atom:link. So per the spec, consumers should expect that extension elements may appear inside atom:link. I do agree that a Simple Extension Element (or several) would be the logical choice for this particular use case, as they offer defined semantics for attaching metadata directly to an entry. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: RNG validators capable of fully using the Atom schema?
On Jul 12, 2005, at 19:16, Norman Walsh wrote: I use Kohsuke's MSV. (msv.dev.java.net) Cool. Thanks. I had allowed relaxng.org tell me that MSV Supports XML syntax only. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: More while we're waiting discussion
On 13/7/05 4:25 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: True, but this doesn¹t detract from my argument that we need to be able to signify a tighter relationship than just ³related.² An aggregator might want to offer different UI for comment feeds, in contrast to merely ³related² feeds. Automatic polling of comment feeds is just one possible behaviour that differentiates the two. An example that comes to mind of different kinds of feeds: say I have a pod-cast with a horkin' mp3 enclosure ... and a link to an Atom Feed Document that contains section by section summaries, complete with some kind of link to the time-point in the mp3. That particular Atom Feed Document would never grow, normally, and thus should not be polled. A user might choose to refresh or reload that Atom Feed Document, just in case some errors were updated (just as we do with regular web-pages), but there wouldn't need to be any reason to *poll*. There are probably many other whole-part feed document scenarios. Quick poll: how many feed readers let the user read the current feed document without first requiring them to subscribe. That is, present the content, along with a button subscribe to future updates. e.
Re: More while we're waiting discussion
On 13/7/05 5:17 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I should clarify that I defer this to the particular relationship type. In an atom:[EMAIL PROTECTED]'alternate'], I do absolutely expect the @href to be dereferencable. What I don¹t see any reason for is to mandate that @href must always be dereferencable, regardless of whether the semantics of the type in @rel would require that or not. I've been thinking .. the attribute is @href, not @uri. That¹s Hypertext REFerence, not Universal Resource Identifier. Ignoring the process for a moment ... could we have @href and then also @idref ... then when we mean to provide a dereferenceable uri we can put it in @href, and when we want to provide an ID reference we can put it in @idref. We can even put both into a link, and if the @href returns a 404 or otherwise indicate it is not the thing being sought, then we could try querying an ID resolver to find the new location. e.
