- From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
- Date: Wed, 14 May 2008 09:25:45 +0300
- To: Andrea Perego <andrea.perego@uninsubria.it>
- Cc: Public POWDER <public-powderwg@w3.org>
On Wed May 14 01:14:56 2008 Andrea Perego said: > >So we have our POWDER documents that we're now getting very familiar > >with and that Andrea is tying down in the XML schema. They're all in the > >POWDER namespace of http://www.w3.org/2007/05/powder#. > > > >Let's now associate an XSLT with that root namespace that does what I've > >been thinking the processor should do and convert the string-based > >elements into regular expressions, retaining all the attribution and > >descriptor sets stuff untouched. i.e. only the <iriset /> elements are > >transformed by this XSLT. > > > >We now have a document that will be in a different namespace, let's say > >http://www.w3.org/2008/05/powder-basic# (the fact that it's taken us a > >year to get to this point is depressing and potentially confusing but > >this is only ever going to be processed by machines, if ever). That > >document would look _very_ similar to a POWDER doc. It's still XML but > >now we only have includeregexp and excluderegexp elements in the IRI set > >(includehosts has disappeared along the way) so just pick those up and > >match the candidate IRI against them. > > Well, this raises an issue. In the current XML schema, it is required > for <iriset /> element instances to include one and exactly one instance > of the <includehosts /> element---i.e., in an IRI set definition it is > required to put a constraint on the host component of candidate IRIs. > The purpose is to avoid IRI set definitions of the type "all the > resources having an IRI path starting with /foo are blue." Of course, we > can drop this constraint, but, supposing that we want to keep it, we > have the following problem: > > 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. > A last question. Do we really need two distinct XML schemas? Actually, > POWDER-BASIC is a simplified version of POWDER, and thus it can be > included as a possible variant in the POWDER XML schema. In other words, > we can have a single XML schema, with two distinct namespace URIs. POWDER-BASIC has only in/excluderegexp. POWDER has a whole bunch of grouping elements. Other than that, they are the same. So the POWDER-BASIC validation is the same as PODWER, after stripping the includehosts, includepaths, etc elements, and removing any "exactly one" or "at most one" constraints associated with these elements. > Moreover, I agree that it is not a requirement for the processor to > enforce the XSL transform rules. And I would add, it should not be in > charge of validating a POWDER doc against the XML schema either. The > only requirement for the processor is to return the description of a > resource upon submission of its IRI. > > Said that, most programming languages currently provide built-in support > for XSLT engines and XML validators, so it would be pretty easy to > extend a POWDER processor with these features. Moreover, in order to be > evaluated, a POWDER document must be valid. So, an alternative option is > possible, namely: before being evaluated by the processor, a POWDER > document is validated and then transformed into the POWDER-BASIC format. > In such a case, a POWDER processor must understand only POWDER-BASIC. This might be a useful suggestion to the implementors, but I don't think it should be a requirement. > About this issue, I think that it might be important to make clear which > are the possible processing steps when dealing with extensions. If I've > understood correctly what you've said, we have two possible processing > options: > > 1. POWDER + extensions -> POWDER ( -> POWDER-BASIC [optional] ) > > 2. POWDER + extensions -------------> POWDER-BASIC No, 2 is: POWDER-BASIC + extensions -> POWDER-BASIC > Provided that we support both, are there any reasons why a specific > extension should use the former or the latter? Some words on this might > be useful to make clear how extensions can be implemented. An implementor might choose to base their implementation on either POWDER or POWDER-BASIC, depending on whether they need URL-specific grouping elements or not. So, the WAF extension will be more sensibly be derived from POWDER, and the ISAN one from POWDER-BASIC. s
Received on Wednesday, 14 May 2008 06:26:28 UTC