- From: Phil Archer <parcher@icra.org>
- Date: Thu, 05 Jun 2008 12:21:20 +0100
- To: Public POWDER <public-powderwg@w3.org>
Smith, Kevin, (R&D) VF-Group wrote: > Hi Phil, > > My understanding was that if we support other identifiers (ISAN, ISBN) > etc. then <includehost>s would not be relevant for those, only for those > retrievable over the Web. True - but POWDER-BASE only has <in/excluderegex> with no other child elements allowed for <iriset>. Things like ISAN numbers would exist in a a format that is not POWDER but that can be transformed into POWDER-BASE. Therefore the question about <includehosts> only applies specifically to POWDER and not BASE or S. > > NB a thought to park for now: so you could describe the characteristics > of a bunch of SMTP addresses using POWDER, couldn't you? That seems > quite powerful. Yes indeed, and POWDER-BASE can do that, therefore conformant POWDER Processors can do that which is, I think, at the heart of the Stasinos plan. > >>> It gives us a way to ensure syntactically that an IRI set is never > empty > It seems like we will need two-step validation due to some features > absent in XML Schema, so this could be picked up by an additional check > (we've mentioned using XSLT as a way to enforce business rules, and also > to create a neat HTML page teling you what the DR says in plain > English). You're saying that we already need a 2-step validation and that we can therefore check that an IRI set definition is not empty without having to mandate <includehosts>? That would be good I think. P
Received on Thursday, 5 June 2008 11:21:57 UTC