zorba-coders team mailing list archive

[Matthias Brantner <matthias.brantner@xxxxxxxxxx>]

> > > > > > > So, should I remove the xml dependency from the function? or
> should
> > I
> > > > > remove
> > > > > > > the whole function?
> > > > > > > If we remove the function the user should be able to create the
> same
> > > > > > function
> > > > > > > by themselves using xqxq:get-type-variable
> > > > > > I think we should remove the entire function. It leaves to many
> > > unanswered
> > > > > > questions. For example,
> > > > > > what if the user wants to pass other parameters to the parse-
> fragment
> > > > > function
> > > > > > or what if the user wants to validate items before passing them as
> > > > > arguments?
> > > > >
> > > > > So I made the following changes:
> > > > > *Removed the implementation of bind-cast-variable
> > > > > *Changed the return value of getVariableType from zorba::String to a
> > > string
> > > > > Item since if the function returns a TypeIdentifier getting a legible
> > type
> > > > of
> > > > > the variable is lost, unless there is a way to get the schema String
> > from
> > > a
> > > > > typeIdentifier?
> > > > I think a string item doesn't make a difference. The type of a variable
> is
> > a
> > > > sequence type that consists of a QName and an occurrence indicator. Just
> > > > having the name doesn't really help. What do you think is missing from
> the
> > > > TypeIdentifier? It allows you to retrieve the URI, local name, and
> > > quantifier.
> > > > What am I missing?
> > >
> > > There are 2 things I miss information about typeIdentifier:
> > > 1. how to create a TypeIdentifier from a XQType
> > Take a look at CollectionImpl::getType in src/api/collectionimpl.cpp.
> >
> > > 2. The function of xqxq is supposed to return the string of type function
> so
> > > getVariableType is returning the XQType toSchemaString so that the user
> can
> > > actually use it to cast the values of the variable, now does a
> > typeIdentifier
> > > has a value like that? Does the localname represents that?
> > The problem is that there is no representation of types in the data model.
> To
> > answer the question we need to investigate the use case. I think the
> function
> > should either (1) return a QName item that represents the name of the type
> > (maybe renaming the function to getVariablePrimeType) or (2) return a string
> > using the sequence-type syntax (e.g. xs:string*, xs:integer?, or
> > Q{http://foo.bar}my-type*).
> 
> As for the purpose of the function, is to allow the user a tool so he can cast
> a string value into the corresponding type of external variable, that's why we
> need the function to return something logical in string which in this case the
> schema string of the type fits perfectly, so an actual type representation of
> the function is not that helpful if is not usable to cast the variable.
> 
> So let me see if I understand your points the first one, is to rename the
> function (which is appropriate) and to instead of returning the string item
> with the value turn it into a QName my only question would be the namespace of
> this QName should it be the same of the external variable? or a new namespace
> referring to this primetype, also I am guessing that the localname would be
> the schema string of the type.
All types are identified by QNames. For example, xs:string is short for
Q{http://www.w3.org/2001/XMLSchema}string. You cannot assume that the namespace
is always the XMLSchema one. The user could have used her own user-defined type
from a schema. That's why the return type should be a QName.

I'm fine if you call the function getVariablePrimeType and make it return a QName.
The C++ API should use the TypeIdentifier.
-- 
https://code.launchpad.net/~zorba-coders/zorba/bug1064978/+merge/150696
Your team Zorba Coders is subscribed to branch lp:zorba.