Re: [XQuery] MS-XQ-LC1-124

Obviously, there's a bug in my code because I forgot to use a namespace 
in the element constructor. I think my point still stands.

You argue in terms of what is "most intuitive for the user". Well, I 
have taught a LOT of XQuery workshops, and my users seem to have a 
different intuition if they are thinking mainly about function 
signatures (where they expect type safety) than if they are thinking 
mainly about path expressions (where they expect element(foo) to match 
any element named foo). But SequenceType is there primarily for function 
signatures, so that should take precedence. In function signatures, I 
think the current definition is what users expect, and we do not need 
one more way to declare "any element whose name is 'invoice', no matter 
what that element contains".

>>    element(my:invoice) - any element named my:invoice
>>    element(global my:invoice) - a valid my:invoice element, as
>>    
>>
>defined
>  
>
>>in the ISSD
>>
>>I don't like that idea for a number of reasons:
>>
>>1. Adding one more distinction to SequenceType is confusing for the
>>user. I do not know enough important use cases for function parameters
>>that specify the name of the element to make this the default for
>>element parameters. This can already be expressed in our current
>>syntax:  element(my:invoice, xs:anyType)
>>    
>>
>
>[Michael Rys] This is not one more distinction. We already semantically
>make that distinction (see schema context path) and is just a natural
>extension of that concept.
>
>Also, note that if you operate on untyped data and perform static
>typing, element(my:invoice, xs:anyType) is useless, since it makes the
>type to be too broad (everything now becomes xs:anyType and
>xs:anySimpleType which will more often lead to static type errors).
>  
>
"Globally declared" and "valid" are two completely different things. 
Your syntax conflates them.

And in a function signature, if I have imported the definition of an 
element, and declared a parameter to be that kind of element, I still 
think that users expect the function argument to match the element 
definition. So we seem to have different intuitions about user's 
expectations. Both of us have talked to a lot of users, I expect they 
may be different users.

>>2. There's no simple keyword that seems to suggest 'a valid element
>>named my:invoice, as opposed to any element that simply has that
>>    
>>
>name'.
>  
>
>>Your suggestion to use 'global' for that is an indication of the
>>    
>>
>problem.
>
>[Michael Rys] This sound like a non-sequitur. If find "global" to be a
>simple keyword. Other proposals are to write element(/name) which has
>the problem that the syntactic difference may be too small. Also note
>that we use global in the validation context...
>  
>
Please explain how "global"  or "/" means "valid according to the ISSD". 
I don't find this intuitive at all. When we use 'global' in the 
validation context it means 'global'.

>> On average, about 80% of elements and attributes in schemas are
>>locally declared, and 'global' implies not supporting valid, but
>>    
>>
>locally
>  
>
>>declared elements using SequenceType.
>>    
>>
>
>[Michael Rys] Your current semantics of element(name) also does not do
>that. So what is your point about element(global name)? 
>  
>
If we adopted your change, how would you want us to match "a valid 
instance of the locally declared element customer, which is found inside 
an invoice element"? Would you say:

    element( global invoice/customer )

If so, I find that even more confusing.

Jonathan

Received on Wednesday, 18 February 2004 16:15:17 UTC