Randy - we've had this conversation before. We had it on Tom Raftery's blog over OPML auto-discovery. And we had it last night in my comments section over OPath. And I'm going to repeat what I said on both occasions: I don't set the standards. I build tools. 
OPath works for things with created attributes and without (by specifying a path through the document). I'm not exactly sure how I can make OPath work outside of the OPath domain name. If you want better control of the service, there are two solutions. Firstly, you use XPath yourself to pull data out in whatever way you find preferential. 
As I've said, I'm going to release the source code for my script that will be havily annotated. The intention is for a hundred flowers to bloom. With both the source code and with DIY XPath solutions, I am perfectly willing to help people build whatever they want. 
I'm not quite sure what Randy's problem is with my use of the URL standard. It's quite a simple URL - you pass two arguments in the URL. The idea is to do it in a way that's less hassle than the old fashioned way. I'm not sure how I should change the URLs in order to conform to standards better. I'll reveal the methods for accessing the URLs in a raw (read, not rewritten) manner in the next day or so. 
Thanks for the feedback Randy, but you seem to be confusing me with someone who sets standards. I don't. I build stuff. Setting standards is a thankless task. I'll state my opinion on how a standard should be, but I don't in any way set them.If someone who does set standards uses what I've done to build or amend a standard - then all the better. 
Adam has suggested using XML namespaces to have a solution. Some kind of new attribute - like an "id" attribute (podcast.com do this, for instance) - could do the job (albeit, there would be an equal number of problems involved in doing so). If that is the case, then I welcome you all to take your suggestions to the relevant OPML mailing list and persuade Dave to put them in to OPML 2.5 or whatever. That's not my job. My role is building tools. And tool-builders have to live with the fact that their materials aren't always perfect. When I hear people say "Why are you bothering with OPML when it's such a sucky format?", my response is usually "well, I'm not particularly bothered about the suckiness of it - I'm concerned that the perfect formats (RDF etc.) are still, for all intents and purposes, research projects". 
If you think you've got a better way of doing OPML ancors than the way I'm doing it, please build it. Or get the idea out there so someone else can build it. I want a solution to the problem. And I know that my solution will get superseded. If it gets superseded by something better, then the aim in it's design has been satisfied. 
Adam Curry's initial podcasting client kind of sucked - but the existence of one generally available tool made it so developers perked up and took notice, and start building more tools. That's something that a standards body or schema can never do. 

