Re: Document order (was: MV Keys)

mAsterdam <mAsterdam_at_vrijdag.org> wrote:

>Christopher Browne wrote:
>> After takin a swig o' Arrakan spice grog, mAsterdam belched out:
>Cheers!
>>>David Cressey wrote:
>>>>mAsterdam wrote:

>>>>>If I change the order of the items in the list,
>>>>>does that make it a new key? I would think so. (See below)

>>>>In other words, an onion and mushroom pizza is different from a
>>>>mushroom and
>>>>onion pizza.
>>>>Here we go again.

>>>Yeah, ehrm well... Is this issue closed? Is there a nice solution?

>>>In e.g. XML the basic assumption is that order has meaning, in SQL
>>>it is that order has no meaning. Historically (XML coming from a
>>>document heritage, SQL from experiments with relational products)
>>>this makes sense, but I would prefer it if one could choose wether
>>>order is meaningful/worth preserving/relevant or not - instead of
>>>being pushed into one way of thinking or another because of the
>>>background of the product at hand.

>> Is it *always* true, in XML, that order has meaning?

>No.

Yes, and no.

>At http://www.w3.org/TR/xpath Chapter 5, Data Model
>says: "There is an ordering, document order, defined on all the nodes in
>the document corresponding to the order in which the first character of
>the XML representation of each node occurs in the XML representation of
>the document after expansion of general entities. "

And particularly - "Thus, document order orders element nodes in order of the occurrence of their start-tag in the XML."

They also, and importantly, are telling you that the structure cannot be taken in just any order. So both superior/parent nodes, at parts of their list, and every of their listed subnodes, is in the order found in the file/document. But not everything is in its proper order, necessarily. Not everything in entity order, if you will. It's just simply in that order. There's are position() function one can use, if one understands how it really works. But it may only reflect only an arbitrary ordering.

So I say yes and no because you are confusing this idea of machine representation with an any intrinic ordering, whenever you speak of - "meaning". A table of contents may be meaningless if one nested category is replaced with one from another part of the book, or swapped with that category under which it ought to appear. Print it that way, it would be called a printer's error, a mistake. If there is no sort element or attribute, if still referring to XML, then one would be dependent on the document/list order of that XML to preserve the entity known as this particular Table of Contents. In fact, XSLT is at its best, if one were to refer to XPATH using XSLT, when simply processing the nodes in document order. It smooths the way and makes potential problems disappear, basically because it is declarative and built to simply offer templates based on the order provided. But if the entity is not intrinsically ordered, then while XPATH will still have position() available, whatever position is unimportant in retrieving that entity. It's components may be in any order. That's all.

This is the question of "meaning", again, not of machine representation or storage methods. It just seems such a simple notion, at least to me.

>> If an XML request for creating a contact submits the <contact:name>
>> before or after the <contact:country>, that is entirely irrelevant as
>> far as any application is concerned.

>Of course. The application can rely on the parser to extract the
>attributes based on the name.

The parser is that which produces the machine representation, built on the XML document and its order, and adds a few things. The serializer 'flattens' the tree, for convenience and other reasons. But for a db group, supposedly, it's probably neither here nor there.

>However, does the a change in the order
>of contacts constitute a different document? AFAIK it does.

Again, it is a different document. But the question was meaning, not whether the letters line up. Does it mean something else? I hesitate to extend - meaning - to mean utility. I really do. But even just as a preference, the order may render the document useful or useless. Doesn't have to be any good reason for that. It just may be. If the contacts are intrinsically ordered, perhaps because one manager insists that it print out this way on everybody's 'prospect' sheet, or whatever, then that order must be accounted, or he'll put back in the order to do it, again. Similarly for country, if a second sort needs to be done on that. He might not have any particularly good reason for sorting like this. But if he's the boss . .

>> In effect, you don't have the result you wish you had; in order for
>> order to be preserved, when it important to do so, it is vital to
>> expressly declare that it needs preservation. XML doesn't help as it
>> does not provide any way to systemically indicate that need.

>How do you declare that it needs preservation?
>I was under the impression that query results were in document
>order - but please correct me if I'm wrong.

Yes, he was forgetting about document order, unless by the word, systematically, he meant to refer to something else.

In fact, the structure, itself, the nesting of those lists, may be arbitrary. The order presented by position() is one thing. That is, document order is one thing. And whether it means something, that's something else. What is an entity, after all? What make it one entity, as opposed to one very much like it? Received on Mon Feb 27 2006 - 05:25:03 CET