Two questions about xsi:type

[Ray Plante]

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?

cheers,
Ray