Re: <item>...</item>

* Kimbro Staken ([email protected]) [031005 21:43]:
> XPath has no problem with namespaces but you have to declare them in a 
> context handed to the processor. I've intentionally ignored namespaces 
> to this point and would actually like to continue to do so for a while 
> longer. My plan is to eventually declare namespaces in the 
> configuration and then make them available to the various XPath pieces 
> all the time.
> 
> There are lots of things that should really be in namespaces, i.e. 
> anything the system ads into the documents like @id and pubDate. 
> However, I've been trying to keep things as simple as possible to make 
> stuff easy to change. Namespaces introduce a level of headaches that 
> drive me nuts. They'll be necessary, but I want to focus on the 
> concepts of the system without that annoyance.

That makes sense to me.  After digging around in the source (and on the
Internet) I checked out the APIs and I found some threads where you
(small world) were discussing the API design for some of the XPath +
namespaces libraries, so the tradeoffs are a bit clearer now.

I've been writing scripts to convert various data stores of mine into
XML suitable for shoving into a syncato install.  I'll probably just end
up leaving out namespaces for the time being (just making them
conditional at import time) and re-import with namespaces later when
it's clearer what The Right Thing is.

It does seem like having the namespaces available via configuration data
would be fine.  I could see some general hairiness when documents come
in with prefixes that cause collisions with already-stored documents,
but for my needs for the indefinite future I can always work around that
-- i.e., you probably won't hear any complaints from me.

I'll probably experiment with providing some xmlns contexts to the xpath
search functions to see if I can extract some documents with prefixes --
if I can extract stored documents I don't really care what sort of mojo
I have to do to set up the query in the first place.

Rick
-- 
 http://www.rickbradley.com    MUPRN: 517
                       |  you get the best that
   random email haiku  |  you can. >Wrong again for the
                       |  above reason.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf