A. Pagaltzis wrote:
>[snip]
>> 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.
>
Heavyweight? It's Java. need I say more?
By "do it properly", I mean being able to provide developers with an
interface that understands the thread extension, it's a difference between:
Option 1, which does not require adding any additional classes
ExtensionElement el = entry.getExtension(thrReplies);
int count = el.getAttribute("count");
Date updated = AtomDate.valueOf(el.getAttribute("updated"));
and Option 2, which does require adding additional classes
Replies replies = entry.getExtension(thrReplies);
int count = replies.getCount();
Date updated = replies.getUpdated();
My implementation supports either.
Getting the resolved href's for the link and replies is simple.
Matching up all of the various equivalents is a pain.
URI uri1 = link.getResolvedHref();
URI uri2 = replies.getResolvedHref();
// normalize and compare the uri's
> 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 )"
> />
>
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>
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.
What's more, for each replies link, I need to iterate through all
available thr:replies elements, resolve, normalize and compare each href.
Pain.
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.
>> 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…
>
;-) Yes, there is a better way, but y'all complained about it ;-)
(sorry, couldn't resist)
>[snip]
> Let’s see if we can come up with something that is as simple to
> implement as possible for everyone…
>
As always, suggestions for spec text are always welcomed.
oh, and btw, draft -09 is now available.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-09.txt
- James
