Re: XQuery & XSLT was RE: Verboseness - XML Syntax for XQuery 1.0(XQueryX)

[Murali Mani <mani@CS.UCLA.EDU>]

> This is an important concern. I think you need to be able to do both.
> Consider the following path expression:
>
>   foo/(*[@baz] UNION bing)
>
> I think that duplicates should be eliminated in UNION, INTERSECT, and
> EXCEPT. What if you don't want that? You can use FLWR, which allows
> iterations over sequences:
>
> FOR $i IN foo/*[@baz]
> RETURN $i,
> FOR $j IN foo/@bing
> RETURN $j
>
> So you can get either result.

I will argue -- Single path expression vs multiple path expressions looks
intuitive to me for getting duplicate nodes or not. Single Path expression
=> no duplicate nodes, multiple path expression => duplicate nodes might
appear. I think the only advantage of this might be that any path
expression will *always* terminate..???

Let me try an example (in some abstract syntax) --

Consider the type definition as
part (name, price, @subParts::IDREFS -> part)

If you just want to know the different subparts of a part, say p1 --
p1/(@subParts->part)*/name
the above will result in no duplicates.

otherwise, do something like

function hedge [part] getSubparts (part p) {
	hedge [part] h1 = p/@subParts->part);
	hedge [part] h = [];
	for (each node n in h1) {
		append (part) n to h;
		append getSubparts ((part) n) to h;
	}
	return h;
}

The query will be getSubparts (p1)/name

the above will result in duplicates.

How do you think??? -- UNION, INTERSECT, EXCEPT are set operations.. their
semantics seem well-defined...??? they are not for dealing with
hedges..???

please note -- I am sure you know -- to me, hedge is an ordered list of
trees, forest is an unordered set of trees ... (i think communication is
cleaner if we use the above convention..???)

> >b) The data model appears still quite incomplete to me -- do you want to
> >use IDREFS to represent ordered list of elements?? --
>
> In general, elements do not have IDs, so this would not work. We use node
> identity, which is an inherent property of the nodes. In an object oriented
> system, you can think of this as the physical address of the node, or you
> can pretend that the system automatically numbers the nodes when it parses
> the document. There are many ways to implement node identity.

I might not agree...??? IDREF is like a foreign key, and IDREFS is like a
collection of foreign keys to me (a collection of foreign keys was never
really there in any other data model before)... I think IDREF(S) represent
an easier way of representing queries and navigation operations than using
joins explicitly... ??? In short, I think IDREF and IDREFS are quite
useful...

> >is document order the only order in which you want to use???
>
> No, of course not.
>
> >for example, consider types --
> >Book, Person, with an IDREFS attribute for Books referring to Person
> >representing the list of Authors in one xml document -- so is there a way
> >of getting the list of Authors as such without using some additional
> >attribute for representing order (as we have to do in the relational
> >model)?? -- I think use of IDREFS for representing ordered binary
> >relationships without attributes might be useful...???
>
> Since most XML does not have an ID for every element, and no XML has ID
> attributes for other node types, the IDREFS trick simply will not work. We
> use inherent identity instead.
>
> I think you are searching for the unordered() function, which allows the
> system to return, say, a list of authors, in any order it finds efficient.
> We also have sorting, of course, which allows you to get things back in the
> order you prefer.

Precisely not -- my questions at this point are those where the user
requires the result in a specific order. Let me give an example --

<Library>
  <Book name="b1" authors="a2 a1"/>
  <Person name="P1" personID="a1"/>
  <Person name="P2" personID="a2"/>
</Library>

Assume that @authors is of type IDREFS, and @personID is of type ID.

The document explicitly says that the authors of b1 are [P2, P1] in that
order, which is not the document order. Do you want to use such an order??

If we support only document order and sorting, then I think the above
data modeling "tricks"??? *should* not be allowed because you can never
get the list of authors of a book in the correct order...???

> You may have noticed the following issue in the XQueryX document:
>
> <snip>
> Issue 8 : Representing // (xqueryx-slash-slash)
>
> Originator: XMLQuery
> Locus: xqueryx
> Description:
>
> In this document we use the constant SLASHSLASH as a fictive axis that
> corresponds to the meaning of the "//" operator. In fact, this operator
> does not correspond directly to an axis, but to
> descendant-or-self::node()/. For example, //para is short for
> /descendant-or-self::node()/child::para. Since XQueryX must be able to
> translate back to the original XQuery syntax, we currently use SLASHSLASH
> to preserve the original operator.
>
> Is this the best way to represent the // operator in XQueryX?
> </snip>
>
> I didn't find a better way to map this into XQueryX.
>
>
> >I think there might be humans who like to take short-cuts, and take an
> >XQueryX query directly and try to modify it -- they might take the
> >trouble to learn XQueryX keywords, rather than use the tool for the
> >conversion -- others getting involved in the project might feel totally
> >out of place if the previous person was using such short-cuts..???
>
> Possibly. I used to have a boss who would change the binaries of my
> assembly programs by hand if the assembler generated the wrong thing. But
> I'm not sure this is what XQueryX was designed for.

That is well said.. My comment was (and is) not strong ... I will say this
-- I think path expressions look good, parsing it and showing it to me, I
think looks bad -- I am *against* representing a parsed form of the path
expression -- why was this reversed in the first place???

thanks and regards - murali.