from:"A. Pagaltzis"


* James M Snell [EMAIL PROTECTED] [2006-06-28 14:35]:
 Hiding the div completely from users of Abdera would mean
 potentially losing important data (e.g. the div may contain an
 xml:lang or xml:base) or forcing me to perform additional
 processing (pushing the in-scope xml:lang/xml:base down to
 child elements of the div.

How is that any different from having to find ways to pass any
in-scope xml:lang/xml:base down to API clients when the content
is type=html or type=text? I hope you didn’t punt on those?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests


* James M Snell [EMAIL PROTECTED] [2006-06-28 20:00]:
 A. Pagaltzis wrote:
  * James M Snell [EMAIL PROTECTED] [2006-06-28 14:35]:
  Hiding the div completely from users of Abdera would mean
  potentially losing important data (e.g. the div may contain
  an xml:lang or xml:base) or forcing me to perform additional
  processing (pushing the in-scope xml:lang/xml:base down to
  child elements of the div.
  
  How is that any different from having to find ways to pass
  any in-scope xml:lang/xml:base down to API clients when the
  content is type=html or type=text? I hope you didn’t punt
  on those?

 Our Content interface has methods for getting to that
 information.

Then stripping the `div` is not an issue, is it?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests


* Henri Sivonen [EMAIL PROTECTED] [2006-06-29 00:20]:
 On Jun 28, 2006, at 23:53, James M Snell wrote:
 or instance, if I have content xml:lang=endiv
 xml:lang=fr.../div/content and I drop the div silently,
 then  I've got a problem.
 
 Dropping the div shouldn't mean dropping the language and base
 URL context. You need to communicate those anyway in the case
 they are  inherited from higher up in the document tree.

Exactly.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests


* Antone Roundy [EMAIL PROTECTED] [2006-06-28 21:30]:
 Consider this:
 
 entry xml:lang=en xml:base=http://example.com/foo/;
   ...
   content type=xhtml
   xhtml:div xml:lang=fr xml:base=http://example.com/ 
 feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div
   /content
 /entry
 
 Whether there's a problem depends on whether one requests the
 xml:base, xml:lang, or whatever for the atom:content element
 itself or for the CONTENT OF the atom:content element, in which
 case the library could return the values it got from the
 xhtml:div. Except in unusual cases like this, the result would
 be identical.

I can see your argument, but I find this too fine a distinction.
The `div` is part of the container when `type=xhtml` as far as
I’m concerned. I’d just merge the information with that on the
`content` element and pretend there’s no difference. As far as
the feed’s *meaning* is concerned, there isn’t, after all.

 * give me the raw contents of the atom:content element
 * give me the contents of the atom:content element converted to
   well-formed XHTML (whether it started as text, escaped tag
   soup, or inline xhtml)
 
 In the former case, keeping the div feels like the right thing
 to do -- the consuming app would have to know to remove it. In
 the latter case, removing the div from xhtml content feels
 like the right thing to do.

Yes, that sounds sane. “Give me the raw contents” would be
somehting only an Atom-aware API client would want to do, so it
is reasonable to expect that the client knows what to do with the
`div` when it finds that the content type was `xhtml`. Anyone who
just wants to use the data and doesn’t want to have to care about
how Atom works should just ask for XHTML and not care what it was
originally packaged as.

 ...now that I think about it, if the library always returns the
 xml:base which applies to the content of the element, that
 could cause trouble too:
 
 entry xml:lang=en xml:base=http://example.com/;
   ...
   content type=xhtml
   xhtml:div xml:lang=fr xml:base=feu/xhtml:a
 href=axe.htmlaxe/xhtml:a/xhtml:div
   /content
 /entry
 
 Here, if I get xml:base for the content of content, it will be
 http://example.com/feu/;. Then, if I get the raw content of
 the element, strip the div, and apply xml:base myself, I'll
 erroneously use http://example.com/feu/feu/; as the base URI
 unless I know to ignore the xml:base attribute on the div.

I agree, but I don’t see how that’s at all to the point. Such an
API client is just buggy. If they ask for the raw `content`
content, then they should also ask for the `content` base URI,
not for the content’s base URI.

Guiding API clients to avoid such a mistake should be reasonably
easy by naming the methods appropriately, ie something like
`get_container_content` and `get_container_base` vs `get_content`
and `get_base`. (That the first pair of names is so long is fully
intentional… :-) )

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [RFC 4287] unicity of atom:category element

2006-06-26 Thread A. Pagaltzis


* Nicolas Krebs [EMAIL PROTECTED] [2006-06-27 00:15]:
 Could an atom 1.0 feed contain some item whith 
 category scheme='http://www.tbray.org/ongoing/tag/' term='Java' 
 somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/' /
 and other item with 
 category scheme='http://www.tbray.org/ongoing/tag/' term='Java' 
 somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' /
 where the first Java is not the same as the second ? 

The term is machine readable. The label is human readable.

category
scheme='http://www.example.org/cat/'
term='http://www.example.org/cat/Technology/Coding/Java/'
label='Java'
/
category
scheme='http://www.exmple.org/'
term='http://www.example.org/cat/Technology/Sun/Java/'
label='Java'
/

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Copyright, licensing, and feeds

2006-06-08 Thread A. Pagaltzis


* Karl Dubost [EMAIL PROTECTED] [2006-06-08 04:30]:
 Which will not remove abuse :)

Well, will anything short of not publishing your content?

I think the point of such an effort is to make life easier for
third parties who want to respect your wishes, not to make it
harder for third parties who are intent on violating them.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: when should two entries have the same id?

2006-06-07 Thread A. Pagaltzis


* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-06-07 20:20]:
 /me wonders how long before a wiki engine based on Atom :)

You mean http://www.xml.com/pub/a/2004/04/14/atomwiki.html? :)

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Sorry this is on-list; Robert does not seem to appreciate off-list mail



Please note the datetimes:


* Robert Sayre [EMAIL PROTECTED] [2006-05-30 22:30]:
 On 5/30/06, James M Snell [EMAIL PROTECTED] wrote:
 
 [snip]


[In a thread which had absolutely nothing to do with James’
extensions:]
* Robert Sayre [EMAIL PROTECTED] [2006-05-31 02:50]:
 The URI/IRI specs say use whatever you prefer. If you don't
 like that, have James add it to his revision of 4287. :)


* Robert Sayre [EMAIL PROTECTED] [2006-05-31 04:00]:
 I think James forgot to cc the list
 
 -- Forwarded message --
 From: James M Snell [EMAIL PROTECTED]


* Robert Sayre [EMAIL PROTECTED] [2006-05-31 04:40]:
 Hmm, do you harass everyone who disagrees with you like this?
 [snip]
 
 On 5/30/06, James M Snell [EMAIL PROTECTED] wrote:
 [snip]


* Robert Sayre [EMAIL PROTECTED] [2006-05-19 22:50]:
 I find interacting with you {{James --Ed.}} to be a giant time
 sink. My new policy will be to explain my problem *once*, and
 then I will verify that my concerns (if any) have been
 addressed at some later date when there is a revised document
 available. If my concerns aren't addressed, I will make a
 concerted effort to avoid writing or being responsible for
 maintaining any relevant functionality.


I have no further commentary to offer.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Link rel test cases


* James Holderness [EMAIL PROTECTED] [2006-05-31 02:40]:
 I agree completely, but as a content consumer I still need to
 know whether to use IRI::Compare or String::Compare when I do
 encounter some ridiculous feed that uses example (a). I'm
 hoping for a simple answer along the lines of Use
 IRI:Compare, Use String::Compare, or The spec doesn't say,
 so you may use whatever you prefer.

RFC4287 defines the relation value in terms of IRIs, but does not
require that relations be compared as such, and then constrains
the set of values to a subset of IRIs. This constrained set is
more amenable to simple string comparison. My interpretation of
these facts is that string comparison is explicitly expected.

Given then that all implementations that I have read the source
of do indeed compare relation values as strings, my conclusion is
that while you are free to compare them as IRIs, doing so is
unwise; likewise, while you are free to specify registered
relation values in your published feeds as absolute IRIs
including the http://www.iana.org/assignments/relation/ base,
doing so is unwise.

The spec indeed doesn’t say, so you may indeed use whatever you
prefer. That does not mean all preferences are equally wise.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]


* Robert Sayre [EMAIL PROTECTED] [2006-05-31 17:55]:
 So please, spare me the lecture. I don't want to get nasty
 emails from James anymore. My problem is solved.

If you hadn’t dropped an asinine jab at him into a completely
unrelated thread you might not have created the problem that you
would then need to “solve” in the first place.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Link rel test cases


Hi Robert,

* Robert Sayre [EMAIL PROTECTED] [2006-05-31 19:35]:
 On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 
 My interpretation of these facts is that string comparison is
 explicitly expected.
 
 Incorrect.

I don’t see how, although I can see how what I wrote might be
ambiguous. Substitute “expected” by “anticipated and provided
for” to get something closer to what I meant, perhaps.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]


* Robert Sayre [EMAIL PROTECTED] [2006-05-31 19:55]:
 On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 If you hadn't dropped an asinine jab at him into a completely
 unrelated thread you might not have created the problem that
 you would then need to solve in the first place.
 
 Actually, those were just the latest two. But you didn't know
 that, did you?

No, I didn’t. You sure picked an unfortunate sample to forward
back to the list, though.

 How about you go back to writing your Atom code?

How about you leave conjecture out of your commentary about other
people’s activities?

 If you have further comments, send them somewhere else. If you
 send them to me, I'll be sure to put them with the other unread
 emails from you.

Duly noted. I only ever remember sending you a single email
anyway, and that was a thank-you note for one really good
criticism you posted here somewhat recently that even refrained
from any personal attacks. What a pity that it would go unread.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Link rel test cases


* Robert Sayre [EMAIL PROTECTED] [2006-05-31 20:25]:
  On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
  
  My interpretation of these facts is that string comparison
  is explicitly expected.
 
 If it was explicit, you wouldn't need to interpret.

Okay, more imprecise wording. Make that “specifically
anticipated.”

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Link rel test cases

2006-05-30 Thread A. Pagaltzis


* Martin Duerst [EMAIL PROTECTED] [2006-05-30 08:00]:
 The conclusion is that a content producer that uses
 HTTP://www.IANA.org:80/assignments/relation/alternate at all
 does something wrong.

+1

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Model vs Syntax (was: Feed Thread in Last Call)

2006-05-24 Thread A. Pagaltzis


* Tim Bray [EMAIL PROTECTED] [2006-05-23 23:40]:
 On May 20, 2006, at 8:49 AM, David Powell wrote:
 Foreign attributes are bad, and are inherently less
 interoperable than Extension Elements.
 
 I would say that furious debates about elements-vs-attributes
 have been going on since the dawn of XML in 1998, but that
 would be untrue; they've been going on since the dawn of XML's
 precursor SGML in 1986. They have never led anywhere. After
 you've noticed that if you need nested element structure you're
 stuck with elements, and if you don't want to have two things
 with the same names attributes can help, there really aren't
 any deterministic decision procedures.
 
 I note with pleasure that *all* known XML APIs allow you to
 retrieve elements and attributes with about the same degree of
 difficulty.

As I read David’s argument, this has nothing to do with elements
vs attributes and everything to do with Extension Elements vs
foreign markup. It doesn’t make a whiff of difference to David’s
argumen whether the Feed Thread Extension standardised on
providing this information as child elements or attributes of
atom:link. The considerations are exactly the same: model vs
syntax.



By and large, I agree with him that it would have been beneficial
to specify Atom just a little more closely at a model level. But
I also agree with you that aspiring to much higher rigor beyond
the Infoset level is unnecessary.

My retrospective opinion is that the correct approach would have
been to specify that an Atom Feed Document consists of a series
of completely independent Atom Entries, each of which can be
interpreted in isolation of any others as well as of the Atom
Feed Document that they are found in (modulo Person Construct
inheritance). This would explicitly allow consumers to rely on
this atomicity (pun intended), thus preventing any extensions
from crossing these boundaries.

This goes beyond the mere interchange of messages to a definition
of a standardised model, though as you can see, it’s a very loose
one. I contend it is also the model used implicitly by any useful
aggregator which tracks feed content over time.

Section 6.4 is more myopic and simultaneously more presbyopic
than that.

This omission shouldn’t matter much in practice. RFC 4287 enables
such a world view implicitly anyway (eg. by only allowing feed
metadata to appear at the top of a Feed Document and declining to
assign any significance to the order of entries). Extensions
which require considering an Atom Feed Document as an overall
unit rather than as a collection will hopefully fail to gain much
acceptance by virtue of high burden on implementors. But being
explicit about this model would have made RFC 4287 a better spec.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Fyi, Apache project proposal

2006-05-23 Thread A. Pagaltzis


* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-05-23 17:20]:
 As we have already seen on this list, RFC4287 lacks of
 precision in some context, therefore I wonder what being
 exactly correct represents.

Did I miss something? I remember several oversights of omission,
but none of imprecision.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread updates

2006-05-19 Thread A. Pagaltzis


Hi James,

* James M Snell [EMAIL PROTECTED] [2006-05-19 20:00]:
 Considerations for using thr:count and thr:when

I’d still like thr:when called thr:updated, as it follows the
same semantics as atom:updated and its value is of the same type.

 That is, the  actual total number of responses contained by the
 linked resource MAY differ than the number specified in the
 thr:count attribute. Feed publishers SHOULD make an effort to
 ensure that the meta is accurate.

This SHOULD seems way too prescriptive. If you keep this sentence
at all, I suggest changing to an informal “may want to.”

 Feed publishers MUST consider a change to the thr:count and
 thr:when attributes to be an insignificant update, meaning
 that the value of the containing feed, entry or source
 element's atom:updated element MUST NOT be affected by a change
 to the values of either of these attributes.

I would clarify this “an insignificant update in terms of RFC
4287”. However, I am not sure what this MUST buys, and more
importantly, how it could be enforced. Suggesting SHOULD instead.

 Lastly, implementors need to be aware that while the Atom
 specification xref target=RFC4287 / explicitly allows the
 link element to contain arbitrary extensions, the specification
 does not require that implementations support such extensions.

This concern could be partially addressed by including an element
to specify a global reply count for an entry in an atom:entry
Metadata element. The cost of such an inclusion is insignificant,
and there are benefits for all consumers, including those which
can support the namespaced link attributes. I strongly suggest
adding such an element.

I am willing to draft spec language for it if you want me to.

 The element is not unlike the references and in-reply-to email message
 headers defined by xref target=RFC2822 /, with the exception that,
 unlike those headers, the in-reply-to element is required only to
 identify the unique identifier of a single parent resource as opposed to
 the listing all of the unique identifiers for each preceding resource in
 the thread.  If the entry is a response to multiple resources,
 additional in-reply-to elements MAY be used.

This is an inaccurate description of the RFC 2822 headers.
Suggest the following:

The element is not unlike the references and in-reply-to
email message headers defined by xref target=RFC2822 /.
However, unlike the in-reply-to header, the in-reply-to
element is required to identify the unique identifier of only
a single parent resource. If the entry is a response to
multiple resources, additional in-reply-to elements MAY be
used. There is no direct equivalent to the references header,
which lists the unique identifiers of each preceding message
in a thread.

 If the resource being responded to does not have a persistent,
 universally unique identifier, the IRI used to retrieve a
 representation of the resource MAY be used so long as that IRI
 could also be used as a valid atom:id value and so long as the
 href attribute is also specified.

It would improve interop if multiple disparate publishers
publishing a response to the same resource were led to pick the
same identifier, so I suggest changing this MAY to SHOULD.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread updates

2006-05-19 Thread A. Pagaltzis


* James M Snell [EMAIL PROTECTED] [2006-05-20 06:40]:
 A. Pagaltzis wrote:
  I’d still like thr:when called thr:updated, as it follows the
  same semantics as atom:updated and its value is of the same
  type.
 
 I'm still stewing over this and haven't quite made up my mind
 on it yet. The only reason I'm not quite comfortable with it is
 that it just seems confusing have both an atom:updated and a
 thr:updated.

How so? I honestly can’t follow that. Explain?

  That is, the actual total number of responses contained by
  the linked resource MAY differ than the number specified in
  the thr:count attribute. Feed publishers SHOULD make an
  effort to ensure that the meta is accurate.
  
  This SHOULD seems way too prescriptive. If you keep this
  sentence at all, I suggest changing to an informal “may want
  to.”
 
 may want to is a little too weak for me, but yes, the SHOULD
 is too much. Let me think about it. If I can't come up with
 something better, I'll use the may want to suggestion.

Oh wait. I was bewildered because I read it as “Feed aggregators”
rather than “Feed publishers.” Sorry! Comment retracted, the
SHOULD is perfectly appropriate.

  Feed publishers MUST consider a change to the thr:count and
  thr:when attributes to be an insignificant update, meaning
  that the value of the containing feed, entry or source
  element's atom:updated element MUST NOT be affected by a
  change to the values of either of these attributes.
  
  I would clarify this “an insignificant update in terms of
  RFC 4287”. However, I am not sure what this MUST buys, and
  more importantly, how it could be enforced. Suggesting SHOULD
  instead.
 
 Making this a MUST will (hopefully) reduce the likelihood
 false-updates for clients that don't understand FTE. That is,
 if I use a client that does not understand FTE and I suddenly
 see an entry that is marked as updated for no apparent reason,
 I'm likely to get quite annoyed after a while.
 
 (note that I included this after running some tests on a couple
 of feed readers and discovered that it is indeed quite
 annoying)

That means it falls into the “compliance cannot reasonably be
tested but non-compliance is likely to cause interop problems”
bucket, which is exactly when a SHOULD is appropriate.

  This concern could be partially addressed by including an
  element to specify a global reply count for an entry in an
  atom:entry Metadata element.
 
 […] I could imagine feed reader implementors being quite pissed
 off that they have to support an element with identical
 form/function/semantics as slash:comments just so feed
 publishers can avoid having to declare one additional xml
 namespace.

I dunno; it seems like a drop in the bucket compared to the rest
of the spec, and if they’ve already implemented slash:comments
semantics it seems like the effort to support an equivalent
element in another extension is minimal.

 Also consider that even if FTE declares a
 thr:count5/thr:count element, most folks are likely going
 to keep on using slash:comments. (I mean, heck, look at the
 number of Atom 1.0 feeds that are still using dc:subject to
 indicate the category!!)

If they were previously already using it, sure. I’m willing to
bet money that next to noone who implemented Atom 1.0 support
from scratch is doing that, though. Rather, I’d posit that these
are (nearly?) all template-based Atom 0.3 implementations that
were upgraded to Atom 1.0 with minimum effort.

I believe that those who come to Atom 1.0 with a clean slate
benefit from the inclusion of a native atom:category element, and
likewise those who come to the FTE with a clean slate will
benefit from the inclusion of a native atom:entry Metadata
element equivalent to slash:comments.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call


* James M Snell [EMAIL PROTECTED] [2006-05-18 17:40]:
 My interpretation of the text and the RELAX NG definition is
 that while the specification does not assign any meaning to
 extensions of the link element, it is nonetheless explicitly
 allowed.

Noone ever debated that.

 It may have been a mistake, but the discussion of section 6.4
 is explicitly scoped *only* to child elements of atom:entry,
 atom:feed, atom:source and Person constructs.

That was a mistake, yes. Unfortunately, hindsight is 20/20.

 Note that this section does NOT state that ONLY those elements
 may be extended; rather, the section defines the
 characteristics of two types of extensions that could occur on
 those subsets of elements. The characteristics of extensions on
 other elements in the Atom vocabulary are left undefined.

Yes. That means extending other elements is a free-for-all just
as it is in RSS 2.0, and we know the problems that this poses in
practice. Extending Atom in ways other than those defined in Sec
6.4. has the same problems as extending RSS 2.0 with namespaced
elements.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call


* Robert Sayre [EMAIL PROTECTED] [2006-05-18 18:05]:
 There's no technical reason for the placement of the
 attributes,

Do you have better ideas on how to provide this information on a
per-link basis? It would help if you actually tried to suggest an
approach instead of bashing what’s there.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call


* Antone Roundy [EMAIL PROTECTED] [2006-05-18 20:05]:
 and in another document:
 
 ct:comment-tracking xmlns:ct=... xmlns:atom=... ...
   atom:link rel=related href=URL of the feed ... /
   ct:entry ref=foo
   atom:link rel=comments href=... type=... 
   hreflang=...  ct:count=5 ct:when=... /
   atom:link rel=comments href=... type=... 
   hreflang=...  ct:count=3 ct:when=... /
   /ct:entry
   ct:entry ref=bar
   atom:link rel=comments href=... type=... 
   hreflang=...  ct:count=0 ct:when=... /
   atom:link rel=comments href=... type=... 
   hreflang=...  ct:count=1 ct:when=... /
   /ct:entry
   ...
 /ct:comment-tracking
 
 Of course the comment tracking document wouldn't only be
 authoritative for feeds that pointed to it with a
 comment-tracking link.
 
 This would require an extra subscription to track the comments,
 as well as understanding an additional format (as opposed to
 just an additional extension--either approach requires SOME
 additional work), but it would prevent unnecessary downloads by
 clients that aren't aware of it, and would reduce the bandwidth
 used by those that are.
 
 This approach could be generalized to enable offloading of
 other metadata that's more volatile than the entries
 themselves.

Actually, you don’t really need another format. There’s no reason
why you couldn’t use atom:feed in place of your hypothetical
ct:comment-tracking. :-) Your ct:entry elements could almost be
atom:entry ones instead, too, except that assigning them titles
and IDs feels like overkill.

The real cost is not the cost of an extra format, but that
implementations then need to understand the FTE in order to know
to poll an extra document to retrieve the out-of-band metadata.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call


* Antone Roundy [EMAIL PROTECTED] [2006-05-18 21:40]:
 The point of the whole exercise is to create a lightweight
 document for volatile metadata. If it's an atom:feed, you have
 to include a lot of stuff that's not needed here--atom:title,
 atom:updated, atom:author, and atom:summary or atom:content.
 Also, you'd need to have an atom:id for each entry in addition
 to the @ref pointing to the entry that it talks about.

I did say that atom:entry is overkill. You could still use a feed
document, though. If you have no atom:entry in it you can elide
the feed-level atom:author, and the other required elements for a
feed (atom:id and atom:updated) seem like a good idea to have in
this sort of document. Only atom:title is unnecessary, but that
does not feel like a big burden.

 Sure, but if they don't understand FTE, they wouldn't know what
 to do with the extra metadata anyway even if it were in the
 main feed.

That is only half correct. The point of Sec 6.4 is to allow
intermediaries at the infrastructure level (which includes things
like the RSS Platform) to store and pass on extension metadata
generically, without having to understand what a particular
extension means. If you put this metadata out of band, then the
application layer has to take on infrastructure layer
responsibilities.

Note that I’m not arguing against the approach. It seems like an
interesting idea. I’m just pointing out that it does have costs.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call

2006-05-17 Thread A. Pagaltzis


* Eric Scheid [EMAIL PROTECTED] [2006-05-17 14:25]:
 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

You mean `hreflang`, not `xml:lang`, right?

I have to say at first blush I don’t see why it should not work,
so I find your thought experiment quite amusing.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

2006-05-17 Thread A. Pagaltzis


* Robert Sayre [EMAIL PROTECTED] [2006-05-17 07:25]:
 I would have said this should go Experimental,

+1

We can wait and see what problems crop up in practice with the
contested attributes, and whether extensibility according to Sec
6.4. ff (or lack thereof) turns out to be paramount or, to borrow
Tim’s turn of phrase, a molehill.

If it works out, just reissue it; if not, there’s room to go back
and fix it.

Sounds reasonable enough to me.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call

2006-05-17 Thread A. Pagaltzis


* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-05-17 20:10]:
 However, if I'm an aggregator I don't need the thr:count and
 thr:when because I will find those information anyway with the
 following process:

Consider the situation where a weblog only has a single global
comments feed – which I strongly favour because having one of
them for each entry just does not scale. Then it’s easily
possible for some comments to have fallen of the bottom of the
comments feed by the time you fetch it to check. In that case,
the information in the attributes will be more accurate than the
process you describe.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call

2006-05-16 Thread A. Pagaltzis


* James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]:
 The slash:comments extension element can be used to provide a
 global comment count that operates independently of the replies
 link.

Supply per-link information as namespaced attributes on link
elements, if you must. I don’t like the idea, but it seems there
is unfortunately no way to associate link-specific RFC 4287
Simple or Structured Extension Elements with a link. (But why
`thr:when` rather than `thr:updated`?)

However, don’t neglect to provide a way to supply a global reply
count. That would break the argument that the FTE covers nearly
every threading use cases without having to resort to a gaggle of
other extensions and hence weaken FTE’s position, IMO.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call

2006-05-16 Thread A. Pagaltzis


* Robert Sayre [EMAIL PROTECTED] [2006-05-17 01:50]:
 You have no technical reason that makes that location
 compelling, and several WG members have questioned whether this
 document adequately covers the area in question.

I have to disagree that there is no technical reason.

There is no way to sanely associate additional information with a
link element. I suggested an approach based on cross-referencing
with the `href` value, but interactions with xml:base invalidate
that approach. Other than `href`, there is no other hook on
`atom:link` which could be used for cross-referencing without
resorting to microparsing hacks.

The root of the problem is a miniscule omission in RFC 4287: Sec
6.4. does not list `atom:link` as a location for Metadata
elements. It should have. The effect is that links in Atom can
only be extended at the XML level, not at the model level.

There is no other reasonable choice for the FTE than to supply
this information as namespaced attributes on the link element.
This is now clear.

I hate the idea as much as you do, but RFC 4287 is what it is.

 In fact, you appear unable to explain the rationale behind any
 technical decision without resorting to circular reasoning,
 logical fallacies, and claims that are outright false.

That doesn’t mean there is *no* reason for any of these technical
decisions.

But I agree that James has advocated the position he chose on
this particular issue extremely poorly, just as you’d have done
your own argument a favour by omitting your interpretation of the
matter as vendor politics.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread in Last Call

2006-05-15 Thread A. Pagaltzis


* Robert Sayre [EMAIL PROTECTED] [2006-05-16 04:45]:
 […]

+1

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread -09 (was: Re: Atom Rank Extensions)


* James M Snell [EMAIL PROTECTED] [2006-05-03 03:45]:
 Ok, so how's this (not word-for-word as I would write it in the
 spec, but you should get the idea)
 
 The ref attribute MUST be an absolute URI that matches a the
 resolved href URI of a replies link character-for-character
 (case sensitive)
 
 In other words;
 
 link rel=replies href=comments.xml
   xml:base=http://example.org/foo; /
 thr:replies ref=http://example.org/comments.xml; ... /

I don’t know if I like it. It really, *really* departs from
“something that’s as simple to implement as possible,” doesn’t
it? Not only is this just as hard for consumers to implement as
previous sketches, it’ll *also* annoy publishers, I think.

Question: what is the reason you are so staunchly opposed to
cloning `atom:link` for the extension’s purposes?

I’m starting to think that that is the only sane answer. If you
want to provide additional information about a link, you need to
associate this information with the link somehow. If you want to
stick to the spec mechanisms for extending the format, then you
have to provide this information in extension elements and you
must not add attributes to the link. So you must identify the
link by one of its attributes. The only attribute of `atom:link`
by which you can identify it at all is `href`. However, if you
factor in xml:base, you’re in a world of pain, and I don’t see
any way out of that.

The only other option I see is a very ugly hack: ride on the back
the `rel` attribute, abusing the fact that a relation may be a
URI to provide an identifier, ie. something like

link
rel=http://purl.org/net/thread/replies?id=x3os882ja;
href=comments.atom
...
/

But that’s so awful and dirty on so many levels that that I have
to go wash my hands now. Ugh.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread -09


* M. David Peterson [EMAIL PROTECTED] [2006-05-04 23:30]:
 Or is something like this simply inviting WAY TOO MANY little
 things to find justification to plug up the collective inbox of
 the community members?

I don’t know. So far during extension development discussions,
only the missing extensibility for links has stuck out as a real
sore point in RFC 4287. Other than that, the spec has stood up
very well with only a few minor errata reported here and there.

At least, that’s my impression; I don’t know what others think,
of course.

Frankly, I would hope there won’t be much interest – cause if
there is, what else would that mean than that we did a shoddy
job? :-)

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread update


* Tim Bray [EMAIL PROTECTED] [2006-05-05 01:50]:
 This assertion that atom:link is not extensible is simply,
 flatly, completely, wrong. I just went and reviewed 4287 and I
 think it is perfectly clear on this. I suggest that interested
 parties review sections 4.2.7, 6.3, and 6.4 and, if they still
 think there is any problem with child elements of atom:link,
 find language in the RFC which says something other than what
 those sections say.

The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread update


* Tim Bray [EMAIL PROTECTED] [2006-05-05 03:50]:
 If it turns out to be useful, it'll stick. Otherwise not.

No doubt; but then why did we need so much verbiage in Sec. 6.4.
and subsections anyway?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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

2006-05-03 Thread A. Pagaltzis


* David Powell [EMAIL PROTECTED] [2006-05-03 11:20]:
 Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote:
  Such URIs have a much more fundamental problem -- they don't
  refer to a stable set of entries, and therefore only act as a
  snapshot of the  *current* feed, chopped up into chunks. If
  the feed changes between  accesses, the client will be in an
  inconsistent state. The client  also has to walk through all
  of the pages every time it fetches the  feed; it can't cache
  them -- which is a primary requirement for feed  history.
 
 I think it would be worth recommending the use of stable URIs
 in the draft.

Considering how fundamental stable URIs are to the FH extension
and how much of the previous discussion has revolved around them,
I’m surprised there isn’t already language to that effect in the
text. In fact, I would have expected a SHOULD or two on this
subject.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread update


* James M Snell [EMAIL PROTECTED] [2006-05-02 07:15]:
 As you can see from the example, the thr:replies/@ref attribute
 points to an atom:id value, and not the URI used by the link.

So fetching and parsing all relevant links is the only way to
know which `thr:replies` element applies to which link, and no
way to indicate a global reply count is available?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


* Robert Sayre [EMAIL PROTECTED] [2006-05-02 05:25]:
 On 5/1/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 * Robert Sayre [EMAIL PROTECTED] [2006-05-02 03:50]:
  especially when changes requested by the community are met
  with hostility and channel flooding.
 
 Did this happen in more cases than the one I'm aware of?
 
 Yes.

Such as?

  When I read terms like more standard wrt the feed thread
  extension, it makes me cringe.
 
 There are obvious reasons why that one is better than the rag-tag
 group of RSS extensions...
 
 Disagree. There is no proof of that.

There is proof that the existing patchwork of RSS extensions is
insufficient. That is enough to convince me that an extension
which addresses their holes is useful.

If addressing holes in existing standards was unnecessary, then
RSS is good enough and the Atom was a giant waste of time.

 I disagree with many decisions in the draft, but that is
 because I think they are misguided, not because I dislike the
 person who wrote them. For instance, every other threading
 extension uses a simple element with a number to represent the
 number of responses.

That is just one case. I agree that the current setup in the FTE
is less than pretty, and I’d like it to change; but I see what
motivated the form of the provided features and so I consider
them incomplete rather than completely misguided.

 This is limited in theory, but in practice, such elements are
 so easy to deploy, they prove valuable.

I agree with that. (See my proposition elsewhere, which would
have provided this as a special case; it does bother me that the
revision that was just published does not provide for this.)

  for that excludes the IETF from defining the problem.
 
 How do you mean? (Question to be taken at face value. I
 honestly am not sure what you mean here.)
 
 
 Defining the charter, etc, etc. It's a good thing to do. Are
 there any WG members left who were around at that phase? I
 joined right around then...

You mean there should be a formal agreed-on statement of what an
I-D is supposed to achieve before the process starts? If that is
what you mean: yes, that is definitely a fine idea.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread update


* James M Snell [EMAIL PROTECTED] [2006-05-02 17:00]:
 I'll go ahead and make the ref attribute optional.

I think that still needs to be accompanied with verbiage about
global vs local reply count though. There should be guidance on
what it means when elements both with and without `ref`
attributes are present on the same entry.

 Regarding the ref vs. href, issue, I really want to discourage
 client implementors from using the thr:replies as a link to the
 comment feed. Having and href attribute in there is inviting
 headaches. Suggestions on possible ways of wording the spec /
 attribute naming / etc would be greatly appreciated.

Okay, I can see that. Harumpf. Not happy; there has to be a way
to associate links directly with `thr:replies` elements and the
only other way than by comparing `href`s that I can think of is
to put a namespaced attribute on the link, which sucks for
reasons we’ve already been over.

Will have to read this revision and think about it.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


* James M Snell [EMAIL PROTECTED] [2006-05-02 19:45]:
 A. Pagaltzis wrote:
  Such as?
 
 Aristotle, I appreciate the intention, but please don't bother.
 It is painfully clear that Robert has no intention of adding
 anything of any real value to the discussion.

I know. However, I despise politics and old boys clubs and prefer
the merit of my decisions to be self-evident, so I’m avoiding any
assumption of any axe to grind behind his behaviour, to see what
should be addressed and how. If there is any meritorious concern
in his objections, I’d like it addressed, regardless (despite?)
of who brought them up and how.

 As far as FTE is concerned, please understand that I am trying
 to find the best way of accommodating a mix between The
 simplest thing that could possibly work with The way things
 likely ought to work.

Absolutely; I pushed for some of the compromises in the current
design myself.

 With the thr:replies element, to do it properly, I have to
 create a new extension element, create a factory, register the
 extension with the parser, etc. Adding in the difficulties
 inherent in matching equivalent href values between the
 atom:link and thr:replies element means that I'm having to do a
 whole lot more work than what is required with the attribute
 approach.

I have to say that your architecture sounds rather heavyweight,
though it could be close to the norm for people who don’t work at
the DOM level. I don’t have experience with that.

To give my experience from the other end, all my work has been at
the DOM level, where the approaches differ only minimally.
libxml2 provides a `getBase` method which makes xml:base support
effortless; when I use XSLT to transform Atom feed documents, I
wrap it and register it as an extension function, so matching
`href`s is trivial:

xsl:key
name=link-to-uri
match=atom:link
use=uri:resolve( uri:base( . ), @href )
/

 So much, in fact, that I'm fairly certain that folks will be
 less likely to implement a FTE that incorporates the
 thr:replies element.

I can see that. Hrmf. There’s gotta be a better way…

I hope though that this also gives you an appreciation for
Robert’s complaint about the lack of a global reply count
provision. He’s right: for simple use cases that sidesteps a lot
of headaches on the consumer’s end.

 So if I seem grumpy and reluctant to change, please try to be
 patient and understand.

Yes, I see now how it comes about.

However, referring to above, plus what we know about the Windows
RSS Platform, please don’t forget the cases other than your own.

Let’s see if we can come up with something that is as simple to
implement as possible for everyone…

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


* Robert Sayre [EMAIL PROTECTED] [2006-05-02 22:00]:
 I've been saying the same thing for weeks. I suppose it's par
 for the course to handwave about them being strictly
 advisory, supply circular definitions for the feature in the
 first place, claim no one will be implementing the feature,
 then claim that someone is, etc, etc.

Yes. I thought those defences were very silly as well.

 You know, stuffing an idea because of who proposed it.

No, not just because of who proposed it, but also because of how.
You objection is not unreasonable, but you phrased it roughly as
“this is useless crap that no consumer is going to want and only
clueless publishers would insist on providing.” What is anyone
supposed to draw from that? Nor did it help to interpret this on
the level of vendor politics: implying that this extension came
to be just because IBM doesn’t want to play ball wasn’t the most
precise way to clarify its flaws. It wasn’t until David gave his
criticism that I saw any serious problem. 

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


* James M Snell [EMAIL PROTECTED] [2006-05-02 22:25]:
 A. Pagaltzis wrote:
  I have to say that your architecture sounds rather
  heavyweight,
 
 Heavyweight?  It's Java. need I say more?

Hehe. I stopped just short of asking “is that in Java?” :-)

 Does your implementation properly handle the following
 (contrived) example:
 
 entry xml:base=http://example.org/foo/bar;
 ...
 link href=../comments.xml rel=replies /
 thr:replies href=http://EXAMPLE.org:80/foo/bar/../comments.xml; ... /
 ...
 /entry

You probably wanted a trailing slash on your base URI, else the
two hrefs are different.

 I know for a fact that Java's built-in comparison functions for
 the URI and URL classes do not.  I have to normalize the URI's
 after I resolve them before I can compare them.

Yeah, I need to do some extra work. I’m using Perl, whose URI
module does most of the work, but not all. Downcasing the host
name, removing explicit default ports, unescaping characters
which can be, and some scheme-specifics are all automatic, but
some things that should be (at least resolving `..` path segments
and escaping slashes in the query string) are not.

I should probably read the relevant RFCs and write test cases,
then file tickets… that stuff is bothersome.

 What's more, for each replies link, I need to iterate through
 all available thr:replies elements, resolve, normalize and
 compare each href.
 
 Pain.

Yeah. At the DOM level you could use XPath to avoid iterating… :-/

 It is possible that the spec could dictate that the thr:replies
 resolved href attribute MUST match the link's href attribute
 character-for-character, making the above example invalid.

That would be a solution. Would it be a burden on publishers?

  I can see that. Hrmf. There’s gotta be a better way…
 
 ;-) Yes, there is a better way, but y'all complained about it
 ;-)
 
 (sorry, couldn't resist)

Don’t be bitter now. :-)  That particularly choice does make
particular sense in your case; but that doesn’t mean it’s the
overall best.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


Hi David,

* David Powell [EMAIL PROTECTED] [2006-05-03 01:15]:
 I don't think you should do URI normalisation. The ref is being
 used as an identifier, you don't do protocol level
 normalisation on namespace URIs or Atom ids why do it here?

That’s a good point; though there’s a slight difference as
namespace URIs must be absolute in the first place.

The `href` isn’t necessarily unique, now that I think about it,
if you play games with `xml:base`:

link href=comments.xml rel=replies /
link href=comments.xml rel=replies xml:base=./foo/ /

Of course, it’s entirely reasonable to declare this madness and
refuse to support it.

Maybe we need something like _A Plea for Sanity_ that Joe English
wrote about namespaces, for xml:base.

 The draft should specify character-by-character comparison of
 the resolved URI's.

Yeah, probably.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


* Robert Sayre [EMAIL PROTECTED] [2006-05-03 03:15]:
  You know, stuffing an idea because of who proposed it.
 
 No, not just because of who proposed it, but also because of
 how.
 
 Sorry Aristotle, you're not qualified to make that statement.
 I've proposed things every which way, so I know the form
 doesn't matter.

Indeed, I’ve only been a witness to the discussion in a few
venues, so I can’t pass judgement about the big picture. I have
to take your word for it.

However, with regard to the part of the picture in which I did
participate, I will go on record to say that you almost never
made it easy for me to consider your position on an issue on
which I was trying to make up my mind when held a strong opinion
about it. And that’s not for lack of willingness on my part, nor
is it because your positions have been unreasonable. I often
wished you’d argue your case better.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions

2006-05-01 Thread A. Pagaltzis


* Robert Sayre [EMAIL PROTECTED] [2006-05-02 03:50]:
 especially when changes requested by the community are met with
 hostility and channel flooding.

Did this happen in more cases than the one I’m aware of? You
know, the one where James eventually caved on both distinct
points anyway?

 When I read terms like more standard wrt the feed thread
 extension, it makes me cringe.

There are obvious reasons why that one is better than the rag-tag
group of RSS extensions required to duplicate even a limited set
of its use cases. We’ve had that discussion in other venues. (If
you do require a blow-by-blow posted here, I can put together a
summary for the WG.)

 By my count, James has 11 drafts in the system, all
 Atom-related. Many of them are copies of existing RSS
 extensions. It doesn't seem appropriate to issue competing
 versions of various extensions from Microsoft, Yahoo et al. and
 claim they are products of community consensus,

Granted, but don’t lump them all together. Some of them *are*
products of community consensus; the Thread extension in
particular got a lot of churn (more than the others by a wide
margin; ~250 posts on this list by my last count, aside from a
dozen weblog threads or so). At least one or two others received
some attention as well (the Licence extension I think? I didn’t
pay much attention to those).

It appears that it would be most productive if you simply express
any specific concerns you have about particular drafts and their
overlap with particular RSS extensions, instead of going for an
ad hominem against James. It worked for David Powell; his
concerns about technical flaws in the Thread extension convinced
James to revise the draft, where your vociferous unsubstantiated
objections had previously failed.

In any case I’m puzzled why you’d start ringing alarm bells just
now. None of these I-Ds are new; they’re all at least several
months old and some have been through a half-dozen revisions and
corresponding announcements. How did they escape your notice for
so long? If they did not, why have they only become a problem
now?

 for that excludes the IETF from defining the problem.

How do you mean? (Question to be taken at face value. I honestly
am not sure what you mean here.)

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom ConformanceTests results and feedback

2006-04-25 Thread A. Pagaltzis

* Sam Ruby [EMAIL PROTECTED] [2006-04-24 03:50]:
It would be helpful if every entry had a distinct atom:id. And
if the tests were valid:

http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fplasmasturm.org%2Fattic%2Fatom-tests%2Fxmlbase.atom

Yeah, I should fix those. I’ve also been thinking about the
suggestions to use `img` tags to make it easy to scan the
results quickly. Likewise I’ve been thinking about Gordon
Weakliem’s comment on the wiki:

I suggest that the tests be documented with respect to the
expected results. For example, TitleConformanceTests is
perfect: viewing the feed tells you what the expected result
is. LinkConformanceTests, OTOH, gives me no idea of what the
author expected to see when viewing the entry in a reader. For
example, what does the author expect to see when viewing the
second entry? If I display only the second link, do I pass? Do
I need to display both links to pass?

I’d like to do more, but writing tests is menial work, and I
don’t have a lot of tuits at the time being. That’s why I asked
about being able to host these at the wiki, so that the touch-up
process would be low-friction.

If you lack tuits to take care of that, I could copy everything
to my site, for the time being, for easier editing.

I make no promises as to when any of that will be, though. :-/

Honestly, I’m a little disappointed that not more tests have been
written so far, and that is has been happening in such haphazard
fashion. Is it really because noone cares? (I suppose I don’t
care that much either, judging by my output.) What would it take
to get more people more involved? Would it help if there was a
list of outstanding testable spec aspects? What aspects need to
be tested (this needs more feedback from consumer developers!)?

Hmm, #atom would be an ideal place to get this done within a
short timeframe, provided a mob got together.

Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom ConformanceTests results and feedback

2006-04-25 Thread A. Pagaltzis


* James Holderness [EMAIL PROTECTED] [2006-04-25 22:15]:
 The aggregator developers are actively hostile towards such
 tests.

Really? I can only think of counterexamples, though my sample is
admittedly tiny. Who are the hostile ones?

Personally, as someone who has written patches for an aggregator
and is flirting with the idea of building one, I would be very
glad to have a defined target to aim at instead of just
eyeballing the overlap between the spec and the code. What sort
of motivation would compel a developer to be hostile toward
tests?

 Feed producers probably find informational tests more helpful
 than conformance tests.

But they are the ones who stand to gain from consistent and
complete implementation of the standard, in the long term.

In any case, can’t we even rally four or five people from the WG
who care enough about the spec to want to do something likely to
increase the chance of good implementations? Where are those who
participated in the interminable flamewars brought on by every
rathole that lay on the way to RFC4287? Have they stopped caring
now, or was all that vitriol just bikeshed painting after all?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread Draft Updated

2006-04-21 Thread A. Pagaltzis


* James M Snell [EMAIL PROTECTED] [2006-04-13 09:05]:
 Maybe, but given that WG messed up in not making the link
 element formally extensible, it's not likely to be pretty.

Yes. WGs mess up. It’s just life. In a perfect world, this would
be different, but Atom took long enough to ship. What we shipped
feels very solid and robust to me, despite the occasional hole or
oversight.

So let’s just accept that what we have is somewhat imperfect, and
try to get as close to pretty as we can within the constraints.

 Also, keep in mind that the uglier and more complicated the
 correct approach looks, the more implementors are going to
 gravitate towards less-than-correct approaches that meet their
 immediate needs.

I know.

 a. Status quo. Leave things the way they are in the current
draft with a firm warning to implementors that not all atom
impls will be capable of supporting them.

-0.5. As David and Byrne pointed out, having this information is
clearly useful, otherwise these attributes would not be part of
the spec; so it’s worth making an effort to make them available.

 b. Drop thr:count and thr:when from the spec.

+0

Though -0.5 if that’s all that would happen. *Some* mechanism for
providing this information should be available.

 c. Create a new replies extension element
thr:replies href=...
 type=...
 hreflang=...
 title=...
 count=...
 when=... /

+0.5

 d. Create a supplemental extension element
 
d1:
link rel=replies href=... /
thr:replies ref=... count=... when=... /
 
Where the ref attribute in thr:replies / is a
unique identifier that can be matched to the
resource linked by the replies link.  If only a
single replies link is specified, ref can be
omitted.  There could be one thr:replies for
each replies link.

+0.5

I’d instead propose a `thr:count` element with content, with
attributes `ref` and `updated` (`when` is too vague, IMO; I’d
prefer names suggestive of RFC4287 vernacular, particularly when
the semantics are comparable). If `ref` is omitted, this is a
global reply count. If it is present, this is a local reply count
for that resource, and the content of the `ref` attribute must be
identical with the `href` attribute of the corresponding link.
`updated` is, of course, optional.

A single global reply count is always permitted, in addition to
local reply counts, of which there may be exactly one per
resource referenced in a `replies` link.

This reduces the typical use case to a single Simple Extension
Element:

thr:count5/thr:count

This accomodates developers with modest immediate needs neatly.

The most complex scenario then looks something like this, where
there are several additional Structured Extension Elements:

link rel=replies href=http://example.org/06/04/21/blah/comments; 
type=application/atom+xml /
link rel=replies href=http://example.org/06/04/21/blah/trackbacks; 
type=application/atom+xml /
thr:count ref=http://example.org/06/04/21/blah/comments; 
updated=2006-04-22T00:50:55+02004/thr:count
thr:count ref=http://example.org/06/04/21/blah/trackbacks; 
updated=2006-04-21T22:21:37+02001/thr:count
thr:count5/thr:count

It’s somewhat ugly, but I think I can stomach it.

How does that look?

So far I’m not decided about whether there should be any language
to suggest some interpretation of a discrepance between a global
reply count and the sum of local reply counts, but I’m leaning
strongly towards no. Since local reply counts would not have to
be given for *every* resource, any constraint that the sum of
local replies match up with global reply count would have to be
qualified to apply only when local reply counts are present for
*all* linked `replies` resources. So not only is it questionable
whether such a constraint would really be useful in the first
place, rather than an unnecessary burden, but it also would be
complex, and yet feeble. That makes it seem like a bad idea.

d2:
link rel=replies href=... /
thr:replies count=... when=... /
 
only one thr:replies would be specified regardless
of the number of replies links. count would be
reflective of the total number of known replies
across all links.

-1. Having per-link information allows mapping scenarios more
complex than the weblog model, such as a Usenet-ish landscape of
multiple related, but independent distributed feeds. I’d rather
not throw those out.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread Draft Updated

2006-04-21 Thread A. Pagaltzis


* James M Snell [EMAIL PROTECTED] [2006-04-22 03:05]:
 grumble ... I'm not really happy with it but this would work.

That’s roughly how I feel about it. :-)

It has in fact been the theme all throughout the Thread extension
development discussion…

 To be absolutely honest, David's comments here [1] really got me
 thinking.

Yeah, same here. Credit for my proposition really goes to him,
because his arguments about this matter (not just there, but
taken in entirety) where what drove it.

 I don't like it; the use of the supplemental element is ugly,

Yeah; well sorta: it’s specifically goobering up the document
with duplicate data in the necessary `ref` attributes that annoys
me. But I can’t think of any prettier approach that satisfies all
design goals as per David’s argument.

 Where that gets nasty, of course, is when the href is relative
 and xml:base is being used to set the Base URI.

Augh. Nasty indeed. However, it doesn’t concern me much, because
in Atom, `atom:link` has no children and only a single
URI-carrying attribution. Extensions will probably avoid adding
namespaced attributes or elements to it (cf. current discussion).
This means there’s little reason to apply an `xml:base` to an
individual `atom:link`.

 The updated spec would have an appendix that would explain that
 previous versions of the extension defined the attributes and
 that some implementations have been deployed that use the
 attributes. The spec will indicate that those attributes are
 deprecated in favor of the thr:count element but that feed
 consumers have the discretion of whether or not to support
 them.

I feel uncomfortable about it being codified for “eternity.”
There are still Atom 0.2 feeds in the wild, even though they’re
extremely rare. And we’re not seeing the end of Atom 0.3 anytime
soon. With that experience in mind I’d really prefer that the
previous approach not be legitimised even slightly, because
that’s likely to lead consumer developers to feel that they need
to support the old approach, and might lead publishers to probe
that support. So I’d prefer that there be some pressure for the
old approach to die quickly before it gets implemented in enough
venues for the Atom 0.3 Effect to set in.

I understand why you want it, though.

-0.5, I suppose?

I don’t know what to say about this.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread Draft Updated

2006-04-13 Thread A. Pagaltzis


* David Powell [EMAIL PROTECTED] [2006-04-13 11:10]:
 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)

Isn’t that what the `type` attribute is for?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread Draft Updated

2006-04-12 Thread A. Pagaltzis


* David Powell [EMAIL PROTECTED] [2006-04-13 00:15]:
 This seems to be the wrong priority to me.

Convincing arguments, IMHO; +1.

James:

As regards Robert’s vociferous comments, you have to acknowledge
that while the rest of the draft was hashed out in several
iterations, these `thr:count` and `thr:when` things snuck in at a
late stage without any discussion.

And, as regards David’s stance, I think it warrants a reminder
that `thr:in-reply-to` started life as as an `in-reply-to` link
relation as well, but we moved away from that because all of our
attempts to twist Atom links into carrying all the additional
semantics we needed ended up looking funny.

So I would argue that the same appears to be a good idea for the
`replies` relation since it grew beyond the scope of Atom links.

I would even argue that what we are seeing here are really the
first observed instances of a general best practice pattern for
Atom extensions:


Trying to extend `atom:link` is bad. If you need more
semantics than afforded to it by RFC 4287, you should
clone it and tweak the copy.


Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed Thread Draft Updated

2006-04-12 Thread A. Pagaltzis


* James M Snell [EMAIL PROTECTED] [2006-04-13 04:10]:
 What I did claim was that there is little to no technical
 justification for exactly duplicating the link element for the
 sole purpose of introducing two new optional attributes...

David countered that having this information is clearly useful,
else these attributes would not be in the spec, which means there
is a case to be made for making sure they’re available to all
clients, even those behind an API that only provides access to
Sec.6 extensions.

 With in-reply-to, the key issue that swung the argument in
 favor of a new extension element was whether or not the
 [EMAIL PROTECTED] attribute value could be an atom:id value or
 whether it had to be a dereferenceable URI. In other words, it
 was quite likely that ignorant implementations would do the
 Wrong Thing with a [EMAIL PROTECTED]in-reply-to].

My memory was different, so I went and re-read the threads.

The non-dereferencable URI issue was an important sideline, but
it was only a sideline in that discussion. If we were having that
discussion now, I agree that it would be a much bigger sticking
point, but back then, it was an also-ran.

The big debate which swayed the issue at the time was having a
mechanism for associating a source link with an in-reply-to link.
We were trying all sorts of funny combinations with things nested
inside the links or the links nested inside other things, IDREF
attributes, and what have you.

In the end, I put a big torch to my own proposition of an
`in-reply-to` link relation to end the madness:
http://www.imc.org/atom-syntax/mail-archive/msg16594.html

 Big difference in this case. There are no additional semantics
 that make the replies link look funny.

It’s not nearly as funny-looking as that crazy in-reply-to
business we came up with back then, conceded.

 Not to be snarky, but that philosophy hasn't exactly worked out
 too well in the past (e.g. the rss 2.0 description tag).

But `description` can only appear once in an item, and therefore
there has to be some precedence matrix between it and its
derivatives. Not so with `atom:link` and clones, all of which may
appear any number of times in an entry, and thus pose no
precedence problem. In other words, comparing the two situations
is not quite fair.

 Bottom line: I'd be far more inclined to either drop thr:when
 and thr:count from the spec or document a clear caveat that the
 two attributes are likely not to be supported in some
 implementations than I would be to use anything other than link
 for replies.

Maybe we can think of other ways to expose this information so
that it fits the Atom extension model? Are those attributes
really the only possible approach to this issue?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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

2006-04-03 Thread A. Pagaltzis


* James Holderness [EMAIL PROTECTED] [2006-04-04 03:25]:
 The way I see it, until a standards body tells us otherwise, we
 are obliged to support the Content-Location header unless we
 can provide a very good argument for ignoring it.

+1, standards aren’t there for people to cherry-pick the parts
they find convenient or useful.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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


* David Powell [EMAIL PROTECTED] [2006-03-31 09:55]:
XHTML 1.0 doesn't support xml:base does it?  As I understand it,
only specs that say that they support xml:base allow you to put
xml:base on their elements, but any spec that allows URIrefs has
the concept of a base-URI, so for envelope specs such as Atom,
you'd expect xml:base in the envelope to set the base-URI for
the content.

To be honest, I’m not sure about the precise spec interactions
for this case. What I do know however is that Gecko respects
xml:base in XHTML content.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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


* M. David Peterson [EMAIL PROTECTED] [2006-03-31 07:55]:
 I speaking in terms of mashups... If a feed comes from one
 source, then I would agree...  but mashups from both a
 syndication as well as an application standpoint are become the
 primary focus of EVERY major vendor. Its in this scenario that
 I see the problem of assuming the xml:base in current context
 has any value whatsoever.
 
 Pick a planet, any planet, and my point suddenly and
 immediattelly becomes relavent.

No. That is only a problem if you just mash markup together
without taking care to preserve base URIs by adding xml:base
at the junction points as necessary.

Copying an atom:entry from one feed to another correctly requires
that you query the base URI which is in effect in the scope of
the atom:entry in the source feed, and add an xml:base attribute
to that effect to the copied atom:entry in the destination feed.
If you do this, any xml:base attributes within the copy of the
atom:entry will continue to resolve correctly.

It’s much easier to get right than copying markup without
violating namespace-wellformedness, even.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: xml:base in your Atom feed


* Sam Ruby [EMAIL PROTECTED] [2006-04-01 01:50]:
 It would be helpful if people were to update:
 
 http://intertwingly.net/wiki/pie/XmlBaseConformanceTests

For that matter, I’ve been meaning to address some weaknesses in
that test suite which Liferea 1.0 highlights. Liferea does URI
fixup for Atom links in its feed parser, but merely uses the
entry’s alternate URI as the base URI when rendering content.
So it succeeds legitimately on cases that test things like
atom:link, but then accidentally succeeds on a number of cases
that involve atom:content where it should be failing.

I’ve been meaning to add some aggressive tests which use xml:base
values that differ drastically from the nearby alternate URIs in
order to smoke out such coincidentally passing tests, as well as
some intentionally evil tests with `type=xhtml` where xml:base
is set on elements inside the xhtml:div. I expect to see a lot of
aggregators fall from grace with such an expanded test suite.

Sam: is it possible to host the test suites directly on the wiki,
by having pages that consist entirely of verbatim text? Ideally,
the content should be rendered inside the wiki chrome using
`pre` tags, but be downloadable without the chome by way of
adding something like `?display=raw;type=application/atom+xml` to
the page URI. That would make it much easier for more people to
pitch in. I find the collection of tests we have so worryingly
minimal; a lot of the currently lesser used corners of the format
are not being tested at all. It makes me nervous that dirty data
based on current incomplete implementation behaviour may become
too widespread for aggregator developers to be able to ignore it.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: xml:base in your Atom feed


* M. David Peterson [EMAIL PROTECTED] [2006-04-01 03:15]:
 Obviously the main wiki would be better, but if this can act as
 a backup plan, then let me know if and when and I will set up
 access to that box for you.

Hosting is not the point. I have webspace and I can link files I
host from the main wiki, as before. Collaboration is the point.
I’m hoping for a way for anyone to pitch in without having to
fight any red tape, so that the test suite can be expanded by
whoever happens to have a spare tuit.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: xml:base in your Atom feed


* Sam Ruby [EMAIL PROTECTED] [2006-04-01 03:40]:
 I am comfortable enough with the moin code base that I would be
 willing to code up a specific action just for this wiki that
 strips leading {{{ and trailing }}} and then delivers the
 results raw, with the appropriate mime type.

Sounds good.

 How does ?action=atomtest sound?

Maybe `action=atom`?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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

2006-03-30 Thread A. Pagaltzis


* Sean Lyndersay [EMAIL PROTECTED] [2006-03-31 04:00]:
This is unfortunate, because HTML itself only allows base
elements in the header (one per page). So if anyone wants to
build a client that displays more than one item at a time using
a standard HTML renderer (and most client render HTML using
someone else's renderer, not their own), they have to go
groveling in HTML to do URL fixup (or use iframes).

That’s exactly the problem currently facing Liferea.

However, exempting [EMAIL PROTECTED]'html'` content from xml:base
processing won’t help.

If the items can come from multiple feeds, such as is supported
by Liferea, then mixing items from an Atom feed that uses
xml:base and other feeds automatically runs into the same issue.
In that scenario, either the tag soup from the other feeds must
be fixed up so the view can be rendered as XHTML (which supports
xml:base in content), or URL fixup needs to be done on the
content from the Atom feed so it can be passed to a tag soup
renderer.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Changing feed thread (was: Re: Atom Thread Feed syntax)

2006-03-25 Thread A. Pagaltzis


* James M Snell [EMAIL PROTECTED] [2006-03-24 21:30]:
1. Do I change in-reply-to id=... / to in-reply-to ref=... / ?

+1, in case my implicit vote isn’t already counted.

2. Do I change thr:count and thr:when to extension elements
instead of attributes on atom:link?

+0; but I don’t plan on using those on either end of the wire.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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


* Eric Scheid [EMAIL PROTECTED] [2006-03-23 17:30]:
If I have an author with the name Bertrand Café, is it
acceptable to put that into atom:author like this;

authorname![CDATA[Bertrand Cafeacute;]]/name/author

No. That means the author’s name is Bertrand Cafeacute; (he must
have had very cruel parents), not Bertrand Café.

or should I be using the unicode numeric entity instead?

Yes. Or use a literal é as you did in this mail, provided you
emit the feed as UTF-8 (or ISO-8859-1, if you must).

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: text/html with mode=xml in Atom 0.3


* James Holderness [EMAIL PROTECTED] [2006-03-23 17:30]:
So is this a bug in the content generator (all the feeds I've
seen appear to be using TypePad)

Yes.

or are you supposed to ignore the mode attribute when the
content type is set to text/html and always treat it as
escaped?

No.

In 0.3, the `mode` attribute was the final arbiter for the form
of the content. In Atom 1.0, its role was subsumed by switching
on the `type` value because consumer developers reported that
this sort of layering was unnecessarily hard to support and
provided no discernible benefit.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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


* Eric Scheid [EMAIL PROTECTED] [2006-03-23 18:05]:
It's true that XML has only a half dozen or so entities defined,
meaning most interesting entities from html can't exist in XML
... unless maybe they are wrapped like in CDATA block like
above?

No, a CDATA block simply means that characters like ,  and 
stand for themselves.

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.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

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