-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote: > Mark Nottingham wrote: >> I'm not convinced it's a great solution, but something like URISpace >> may be appropriate; >> http://www.w3.org/TR/urispace.html > >> What's nice about this is that you buy some efficiency by walking down >> the tree, rather than evaluating a linear set of rules... > > Interesting spec: I can see uses for it elsewhere. A quick question, > (since grubbing around shows you to be the author;): in section 3.3, > "Path Segments," the semantics of <path match="foo"> are to match the > "next" element in the current path, right? Rather than matching any > random element (CSS style), or (for instance) the last element (which > would be useful in particular for the empty pattern and filename globs). > > Is the spec frozen / dead, or could we suggest additions? E.g.: > > <path any="archives"> > > and: > > <path last=""> > > I can certainly put such extensions into another namespace, but they > seem reasonably tightly connected to the existing "first match" semantics.
BTW, I have banged out a Python implementation of a good bit of the spec, including extensions for "last element" and "any element" path selectors. I plan to use the library in conjunction with various WSGI middleware to allow for URI-based selection of things like theme, role grants, and caching headers: http://pypi.python.org/pypi/repoze.urispace (I'll work on getting the ReStructuredText on that page to render later). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuZh2+gerLs4ltQ4RAgzmAJ40134AsAKppeA2sI1V9Ms4r67rMACgiGG+ yBJxxO12RBUI5YXmdCORo4E= =hTI9 -----END PGP SIGNATURE-----
