Schema Typed Parameters and Return Values in Library Modules

[Daniela Florescu]

Michael,

thanks for your feedback.

Unfortunately in XQuery there is not enough past evidence about usage  
patterns
while designing and developing large module APIs, shareable across  
XQuery processors.

That's why we are asking this question.

As users, how would you like to use it ?
Strict coupling of modules (programming language, Java-style), or  
loose coupling (Web, REST-style)?

We definitely understand that there are advantages and disadvantages  
for both.

Some more comments bellow.

On Jul 19, 2010, at 3:46 PM, Michael Kay wrote:

> I think if I were writing a library for a vocabulary where schema  
> validation is the norm (like FpML, say),

What would you do for the EXPath's HTTP module ? Or for the geo- 
location module (KML, etc) ?

> and assuming that the schema is suitable for use in XQuery (most  
> element names either global or having a named complex type) then I  
> would declare the functions with types that assume the data is pre- 
> validated.
>
> I wouldn't expect client code to be invoking validate{} explicitly -  
> I would expect that most of the time, the function is called to  
> operate directly on input data, which is validated at source outside  
> the query. (But that might not be how Zorba works, I don't know.)

Zorba is agnostic. It will work on whatever XDM instance is given to  
it, as the XQuery specification says.
At *some* point the data has to be validated outside the module, if  
the module's API looks like this:

declare function foo:bar($param as schema-type(aa:bb))

>
> The main reason is that it's a good idea in an interface definition  
> to be as precise as possible about what you expect to cross the  
> interface. It helps users reading the code to know the expectations,  
> and it helps the compiler too.

You are of course right. But on the other hand, too strict coupling  
can hurt the schema evolution.

Any feedback is welcomed.

Thanks, best regards
Dana


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20100719/a590b839/attachment.htm