Two questions about xsi:type

[Aurelien Stebe]

Hi all,

Well, we talked about this in Victoria, but couldn't find a quick 
solution during the session and agreed to postpone the issue (if my 
memory is still working right). I think it would be nice if we could 
find a solution for this that is simple enough and that we can include 
in the RI v1.0

There are two xPath types where "xsi:type" poses a problem.
First, to query on a "Capability" of a certain type, I  would go for "   
where Capability/@xsi:type = 'sia:SimpleImageAccess'  " : keep @xsi:type 
as an exception as you said Kevin, and standardise the namespace prefix 
of the type. It could be written in the RI that the namespace prefix 
used in the extension schema MUST be the one used in the query. This 
could be solved using the @standardID attribute instead of the @xsi:type 
for Capabilities, but we would have the same problem for Interfaces.

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

Solution #1 problem was discussed in Victoria : "maxRecords" is not used 
only in SIA Capabilities, so the query is not exactly what we want.
Solution #2 problem is that it doesn't indicate the query is on 
Capabilities and not Interfaces. If this is not an issue, I would vote 
for this solution, otherwise ....
I would vote for solution #3 with the same restriction on namespace 
prefixes as above. (this was actually Tony's idea if I remember correctly).
This would be easy for XMLDB Registries to replace it with 
"Capability[xsi:type = 'sia:SimpleImageAccess']/maxRecords"  using 
regexes for example. In the ESAVO Registry we use a mapping file to 
point to the actual Table.Column concerned, so I can use any string to 
do the mapping. What about other RDBMS Registries ? Ray ?

On more or less the same subject. Do we start calling those uTypes and 
use "." separators, ask the DM group to change their uTypes or keep 
those two separated ?
If we want to fuse xPaths and uTypes, this issue should be talked with 
the DM group too, as they might encounter this problem, using the STC 
for example.

Cheers,
Aurelien

KevinBenson wrote:
> As I am modifying the RI doc, I noticed two questions that we did not 
> quite discuss or resolve unless I was out of the room :)
>
> 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.
>
> 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?, obviously you can do a "where @xsi:type like 
> '%SimpleImageAccess" hence query via substring, but probably not the 
> best solution, but would work for everybody. Or can we say there is a 
> predefined prefix such as sia, vs, cs?  (this might be the most ideal 
> solution since we tend to always use the same prefixes even on 
> extensions we seem to always use the same such as ssa: or cea:)
> As you might be able to see a relational db could sort of handle it 
> better because most likely a table is named SimpleImageAccess and they 
> can just strip the "sia:" prefix piece to query the table,  but 
> current looks of an xmldb might not be as easy seems to treat the 
> xsi:type like a regular string.
>
> cheers,
> Kevin