- From: Andrea Perego <andrea.perego@uninsubria.it>
- Date: Wed, 14 May 2008 15:33:02 +0200
- To: Public POWDER <public-powderwg@w3.org>
Hi, Phil. Yes, we haven't explicitly stated that includehosts is mandatory, but there has been a lot of discussion related to the specification of "safe" DRs, and the requirement concerning includehosts has been mentioned. This is why I've included it in the *provisional* XML schema. Anyway, if everybody agrees that the only requirement is that <iriset /> is not empty, I can update the schema accordingly. Andrea parcher@icra.org wrote: > A train near Frankfurt station is not ideal place to write this. If I had > more time I'd head for T-Online Allee and drop in for a Kaffe and Kuchen > with Kai but, alas, Nuremberg awaits. So let me chuck in a couple of minor > things while I meander along the River Main. > > As far as I can recall, we have never said that includehosts is required. > We have said that an IRI set MUST NOT be empty, but I believe > > <includeregex>.*</includeregex> > > however unwise, is valid. > > But, I have thought that we might want to make includehosts mandatory. > ICRA labels will certainly all include this element, Even so, I'm not > convinced that it's necessary. If it is not possible to use XML Schema > language to require at least one child element of <iriset /> then, OK, > maybe we need it. Maybe others can comment - this fence sitting is > becoming painful! > > Secondly, I made a mistake in the origianl e-mail. As Stas says, a generic > POWDER Processor really only needs to understand POWDER-BASIC. However, I > propose that whilst that is the conformance criteria, we should also say > that unless the processor is closely tied to a specific extension that > only makes use of BASIC, a typical PP will also understand POWDER. In > other words, if you are setting up a PP as a front end to a database of > ISAN numbers, you don't need to implemenet includehosts, but if you're > using includehosts, a good processor will not necessarily need to go > through BASIC to handle it. > > Phil. > >> On Wed May 14 12:08:07 2008 Andrea Perego said: >> >>>>> The proposal for the POWDER-BASIC schema requires just includeregexp, >>>>> i.e., it does not require any constraint on the IRI host. This means >>>>> that, if a POWDER-BASIC document is obtained from a POWDER one, the >>>>> constraint on the IRI host is kept, since it is in the original >>>>> POWDER document. However, if anyone writes directly his/her own >>>>> POWDER-BASIC document, we cannot be sure that the constraint on the >>>>> IRI host will be kept. >>>>> >>>>> So, we have two options: >>>>> >>>>> 1. Drop the constraint on the IRI host: in such a case, this won't be >>>>> required by POWDER, and POWDER-BASIC will be as proposed. >>>>> >>>>> 2. Keep the constraint: in such a case, the POWDER XML schema won't >>>>> be changed, but we have to put such constraint in the POWDER-BASIC >>>>> XML schema. I see here a possible option: the POWDER-BASIC XML schema >>>>> requires one and exactly one instance of <includehosts /> AND >>>>> <includeregexp /> in an <iriset />. >>>> The whole point of POWDER-BASIC is that it knows nothing about >>>> <includehosts />, so (2) is not possible. >>>> >>>> (1) is possible, but unnecessary. We can keep the POWDER constraint, >>>> and >>>> not worry about POWDER-BASIC (or, for that matter, POWDER-S) authors. >>>> >>>> Implementors of POWDER-BASIC extensions will have to specify their own >>>> constraints, depending on their domain and target audience. >>>> >>>> So, I suggest: >>>> >>>> 3. Keep the constraint: in such a case, the POWDER XML schema won't be >>>> changed. Futhermore, not all POWDER-BASE documents can be turned into >>>> valid POWDER documents. This looks OK, there is no reason to guarantee >>>> the convertibility in this direction. >>> I was not proposing to keep the constraint on the IRI host with the >>> purpose of converting POWDER-BASIC into POWDER. The problem is, as I >>> said, that, if only includeregexp is required, I can write a >>> POWDER-BASIC document claiming that "all the resources hosted by any >>> host, and having a path starting with /foo, are blue." Should we allow >>> this? >> POWDER-BASIC knows nothing about hosts and paths, it only knows how to >> match IRIs against regexps. So, yes, POWDER-BASIC authors can write >> overly generic regexps like "http://[^/]+/foo" or even ".*" if they >> really want to. >> >> Note, however, that POWDER-BASIC is not meant for POWDER authors but for >> POWDER extension developers, who should know better than to define an >> extension that allows this to happen. See how POWDER requires >> includehosts, ISAN could, for example, require includeroots, and so on. >> >> s
Received on Wednesday, 14 May 2008 13:34:01 UTC