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

I think we just have to agree to disagree. My user community does not
see element(foo) to refer to an ISSD unless one tells them repeatedly.

As to naming local elements (disregarding for the moment that I think
XQuery 1.0 can do without), we can use either

element(/invoice/customer) if we use element(/invoice) 

or continue to use 

element(invoice/customer) if we use element(global invoice).

Neither of which seems to be problematic...

Michael

> -----Original Message-----
> From: Jonathan Robie [mailto:jwrobie@mindspring.com]
> Sent: Wednesday, February 18, 2004 1:13 PM
> To: Michael Rys
> Cc: Daniela Florescu; public-qt-comments@w3.org
> Subject: 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:20:26 UTC