Two questions about xsi:type

[KevinBenson]

Wonderful stuff, I have a thought/solution on handling prefixes at the 
bottom of this e-mail (and it could help solve xsi:type problem with 
Capabilities).  Give it a read and see what you think.

Ray Plante wrote:
> Hi,
>
> (Sorry for the delay.  Aurelien's reply made me notice that I missed this
> email.)
>
> On Thu, 25 May 2006, KevinBenson wrote:
>   
>> 1.) As noted XPath will no longer need prefixes hence vr:title will now
>> be title because of the schemas being elementformdefault="unqualified".
>> Should @xsi:type be an exception? (Currently as I work on my laptop I am
>> placing it as an exception, so is that correct?)  I am not certain yet
>> if any of our schemas define an attribute named "type"  As you can see
>> though "type" attribute in the nonamespace is different from an
>> "xsi:type" attribute.
>>     
>
> unqualified does not apply to global elements or attributes; xsi:type
> falls into this category.  I think it seems reasonable to specify that in
> the context of an ADQL xpath that "xsi" be assumed to refer to the
> http://www.w3.org/2001/XMLSchema-instance namespace.
>
> On Thu, 25 May 2006, KevinBenson wrote:
>   
>> 2.) If I wanted all the SimpleImageAccess Types I would have some kind 
>> of query that would normally do  "where @xsi:type = 
>> 'sia:SimpleImageAccess'".  How are we to handle the prefix piece on the 
>> @xsi:type?, 
>>     
>
> The way I understood our conclusions at Victoria was that...
>   *  we didn't have enough knowledge to come up with a solution then,
>   *  we would accept the limitations of the ADQL-based query, and
>   *  we would experiment with new ideas such as Aurelien suggested 
>
> On Thu, 8 Jun 2006, Aurelien Stebe wrote:
>   
>> Second, to query on an element of a certain "Capability" type, I see 3 
>> solutions :
>>   1/   where Capability/@xsi:type = "sia:SimpleImageAccess" and 
>> Capability/maxRecords > 10000
>>   2/   where SimpleImageAccess/maxRecords > 10000    |OR|    where 
>> sia:SimpleImageAccess/maxRecords > 10000
>>   3/   where Capability(SimpleImageAccess)/maxRecords > 10000    |OR|    
>> where Capability(sia:SimpleImageAccess)/maxRecords > 10000
>>     
>
> What I would prefer us to do is write the simple alternative, #1, into RI 
> v1.0, but actually begin implementing #3.  That is, it seems to me that if 
> you support #3, then you can still support #1, and thus be compliant with 
> the standard.
>
> It sounds like #3 is readily doable for Aurelien.  If we can (later) do 
> that with the NVO RDBMS registry and the various XML registries, then we 
> can pretty easily issue an RI v1.1 (as early as May 07) that adds #3 to 
> the standard without much of a disruption.  
>
> We still need to address the prefix issue.  We can't write into RI v1.0 a 
> predefined mapping of prefixes as this does not help with new or 
> non-standard extensions.  I'd like to suggest two possible solutions.  
> Recall that the original suggestion for restricting xpaths is to allow a 
> static mapping of xpaths to columns without parsing the xpath.  In that 
> spirit, my 2 alternative suggestions...
>
> 1)  No special handling of @xsi:type queries.  We recommend that clients 
>     select by xsi:type either with 
>
>        @xsi:type like "%Service"
>
>     which selects all types ending in "Service", OR
>
>        @xsi:type like "%:Service"
>
>     to select only generic services.  
>
> 2)  Define a special handling of @xsi:typ queries.  If a query contains
>
>        @xsi:type = "Service"
>
>     it must be interpreted as '@xsi:type like "%:Service".
>
> Both of these require that publishers explicitly provide namespace 
> prefixes for all xsi:type names (a good idea).  It also encourages 
> registries store the full qualified type name in the database.  Both these 
> should be noted in RI.  
>
> Would this work?
>   
Number 1 and 2 does work, but still not sure if I like it as the 
solution mainly because I would prefer (in a XMLDB) to do an "=" vs. 
substring kind of matching on xsi:type.  Myself and a fellow developer 
were talking the other day and one possible thought (or solution) is:

What if you defined a required (most likely"fixed" attribute) lets call 
it "type"  (NOT xsi:type).  This type attribute would be fixed on all 
the extensions.  (or at least vr:Resource extensions and if you desire 
on other extensions such as Capability or Interface).
ex:  DataCollection would have a required fixed attribute of simply 
"DataCollection"  (type="DataCollection") or
<xs:attribute name="type" type="xs:string"   use="required" 
fixed="DataCollection"/>

If desired you can do it with Interface such as ParamHTTP.   Well you 
might see where I am going with this, if you did the above with our 
schemas then essentially xsi:type can be dropped from queries and no 
more headache with prefixes with queries, and you could even potentially 
say in the RI doc to NOT query on @xsi:type but on the "@type" 
attribute. Of course a downside is a small change to the schema's and 
does look a little redundant since you will have a very similar 
attribute in xsi:type, but it could still be a good solution to our problem.

cheers,
Kevin
> cheers,
> Ray
>
>
>