Code review comment for lp:~zorba-coders/zorba/bug900677

William Candillon (wcandillon) wrote :

> > Should the actual atomic type be present in the attribute element?
> What's the use case for this? The type is declared in the index which should
> be know by the user. It could be done but it's not clear how this would look
> like. Do you want the QName of the atomic type of the sequence type?
> > If you have "by @id" where @id can be 1 or "1", you might want to create two
> > index keys?
> I don't understand this.
Is it possible to have an index key as xs:anyAtomicType?
If yes, you might have an index key of value xs:string("1") and another key of value xs:integer(1).
Is this use case possible?

> > If a key returns (), you might want to distinguish with empty string for
> > probing later?
> I have made a fix such that the value attribute is only present if the entry
> is not the empty sequence.
Consider the following index key declaration:
by xs:string(@team) as xs:string,
   xs:string(@country) as xs:string?,
   xs:string(@league) as xs:string?;

If keys() returns:
  <key value="Foo" />
  <key value="Bar" />
It's not good because I cannot probe the index with this info.
Does it makes sense?

> > By using keys(), I got the following output:
> > <key xmlns="http://www.zorba-
> >"><attribute
> > value="hello"></attribute><attribute value="4"></attribute></key>
> >
> > Is the namespace useful or does it just make the life of the user harder?
> It's consistent with the keys function of the maps module. We can remove it
> but should remove it for both then (which is a backwards incompatible change).
I would fix it here and fix it for map() in 3.0.
Except if the local name attribute means something.

> > Why isn't it:
> > <keys><key value="hello" /><key value="4" /></keys>
> > Again, could you explain me how I'm supposed to probe from such XDM if one
> of
> > the actual key returned empty sequence?
> Is there a way to probe for entries where one of the keys is the empty
> sequence? I don't think there
> is. We should have a separate bug for this.
In Sausalito it's possible.
It was the only way to replace a particular query with an index.
How do we go forward on this?

> > Should the keys have a position attribute or something?
> The index of the attribute elements determines the position. Is an additional
> attribute really needed?
> > The doc/zorba/xqddf.dox doesn't seem to mention the function, it should no?
> Yes, that's done.
> > > The xqdoc seems to have a formatting problem: the output example for
> keys()
> > goes out of its box.
> Fixed.

« Back to merge proposal