RE: XSLT question

To answer the easy question:

>> Does the output of an XSLT have the same URI as the input?

Not always, XSLT processors may change the output file name (and hence
the output URI will differ). Requesting an IRI/URI *may* result in the
XSLT output being sent. However XSLT (or many XSLTs) may be pipelined in
order to create the output, which confuses things further. 

-----Original Message-----
From: public-powderwg-request@w3.org
[mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
Sent: 21 April 2008 14:35
To: Public POWDER
Subject: Re: XSLT question


OK, can we resolve this on the call in a couple of hours please?

And here's a related question. Does the output of an XSLT have the same
URI as the input?

I ask because we might have things like this:

<descriptorset xml:id="descriptorset_1">
   <ex:property1>value</ex:property1>
   <ex:property2 ref="http://www.example.org/descriptions.rdf#Class" />
</descriptorset>

Which transforms into ... what? This?

<owl:Class rdf:nodeID="descriptorset_1">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="&ex;property1" />
       <owl:hasValue>value</owl:hasValue>
     </owl:Restriction>
     <owl:Restriction>
       <owl:onProperty rdf:resource="&ex;property2" />
       <owl:hasValue
       rdf:resource="http://www.example.org/descriptions.rdf#Class" />
     <owl:Restriction>
   <owl:intersectionOf>
</owl:Class>

Which looks wrong and, well, suppose
http://www.example.org/descriptions.rdf#Class is a POWDER descriptor
set, we now have an 'RDF resource' of something that probably isn't RDF.

Which, I think _might_ mean that we have to put some very tight
restrictions on what can be in the descriptor set - i.e. you can only
have string literal values. You can refer to an externally defined
descriptor set /instead/ of a local one, i.e.

<descriptorset ref="some_other_descriptor_set" />

but you can't mix and match.

Alternatively, maybe we need to devise a system for pointing separately
to the POWDER and POWDER-S versions of the external file? Which sounds
horrible.

The original idea was that the descriptor set would be arbitrary RDF/XML
(as long as you don't create any blank nodes) but we seem to have gone
passed that, am I right? I think the original idea (discussed in Athens)
was that we'd have

<descriptorset xml:id="descriptorset_1">
   <ex:property1>value</ex:property1>
   <ex:property2
      rdf:resource="http://www.example.org/descriptions.rdf#Class" />
</descriptorset>

i.e. using rdf:resource, not ref, and we'd have this hybrid of XML and
RDF/XML. In this case the transformation for the descriptor set is "copy
verbatim" - but this ends up with an RDF description, not an OWL class,
which I think is the problem.

Hmmm...

Phil

P.S. About to pop out for a while, back _just_ before the call.





Stasinos Konstantopoulos wrote:
> My suggestion in this, and similar, situations is to never try to get 
> smart with the XSLT transforms, because that's an unnecessary 
> complexity that is, sooner or late, going to come back and bite us. 
> Gratuitous unions and intersections do no harm, and make it easier to 
> validate the XSLT as there are fewer cases and combinations to check.
> 
> A human directly writing in POWDER-S is welcome to optimize it, we 
> never promised that it can get transformed into POWDER/XML anyway.
> 
> s
> 
> 
> On Mon Apr 21 12:50:28 2008 Phil Archer said:
> 
>> I guess this is mostly for Kevin but anyone's free to chime in ;-)
>>
>> [...]
>>
>> Assuming this is right, here's the question - can the XSLT work out 
>> whether or not the unionOf is necessary so that where there is only 
>> one IRI set (i.e. 99% of the time) it can drop the unionOf 
>> properties? Or will we often have a union of 1? The same goes for the

>> IRI sets themselves where in many examples we have intersections of a

>> single property restriction.
>>
>> Basically I guess it's a trade-off between processing complexity and 
>> redundant data. So which wins? (and remember, it's 12st April 
>> already...)
>>
>> Phil.
> 
>

Received on Monday, 21 April 2008 13:59:25 UTC