* 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/>
