- From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
- Date: Tue, 9 Dec 2008 18:15:15 +0200
- To: "Hammond, Tony" <t.hammond@nature.com>
- Cc: Phil Archer <phil@philarcher.org>, public-powderwg@w3.org
Tony, hi. On Tue Dec 9 15:27:24 2008 Hammond, Tony said: > I understand that the limitation to authprity-based URIs ("//...") may be be > predicated on pragmatics and appreciate you pointing out the POWDER-BASE > workaround for generic regex'es. (It is a shame though that some URIs are > treated as more equal than others but then that's just a pet gripe of mine. > ;) If I may same so, it would, indeed, be a shame if some URIs were treated as more equal than others, but they are not. In fact, this WG has spent a significant proportion of its total effort in making sure that there is nothing specific to resolvable URLs lurking in POWDER's foundations. The formal essence of the grouping-by-name mechanism is the BASE and OWL/RDF formalisms. Application builders are free to define any <in/exclude*> grouping restrictions they like, as long as they can be translated into <in/excluderegegexp>. There is nothing special whatsoever about <includehosts>, except that the WG bothered to define it (again, NOT in POWDER-BASE but in POWDER/XML which is specifically targeted at the web). Note how POWDER/XML is defined using POWDER-BASE primitives making no special concession to better or more easilty accommodate resolvable things. This has, by the way, cost us port ranges since numeric comparisons are really hard to "emulate" with regexps, but we didn't want to add any URL-specific portrange elements in -BASE. Note also how in the grouping doc we use POWDER-BASE primitives to define grouping elements for (non-resolvable) ISAN-number URIs. This is, IMHO, one of the strongest aspects of POWDER: we expect that it is mostly going to be used in web applications, but there is no "increased equalness" whatsoever towards resolvable URIs. Going back to the beginning of the thread, we anchor <includehosts> restrictions on :// and keep other IRIs from matching. This is a feature, and a good one IMO, not a bug. Would you *really* want that <includehosts> restrictions can match a <urn:ISAN-number> IRI? Do you have a use case in mind where one would need that? Best, s
Received on Tuesday, 9 December 2008 16:17:48 UTC