zorba-coders team mailing list archive

[Juan Zacarias <juan457@xxxxxxxxx>]

> > > > > > 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.
As for your second suggestion I don't understand what you mean by it, are you talking about the xqxq.xq description of the function or the new dynamic context function? the xqxq one is already returning something like that and the dynamic context one you mean to return a Sequence? or what do you mean? 
-- 
https://code.launchpad.net/~zorba-coders/zorba/bug1064978/+merge/150696
Your team Zorba Coders is subscribed to branch lp:zorba.