Document order (was: MV Keys)

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.

No. Coming from a document background, its *basic* assumption is that order is significant.

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. "

> I don't think that's so at all...
>
> There may exist cases where relative order can have meaning, but there
> certainly exist cases where it is irrelevant.
>
> For instance, RFC 3733 describes an XML schema for representing
> contact information (the sort of information that the WHOIS service
> reports for the various sorts of organizational contacts).
>
> In that schema, order is normally expressly NOT significant in
> indicating meaning.
>
> 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. However, does the a change in the order of contacts constitute a different document? AFAIK it does.

> More pointedly, the domain representation, in RFC 3731, can associate
> multiple nameservers with a domain.
>
> The canonical example is:
> <domain:ns>
> <domain:hostObj>ns1.example.com</domain:hostObj>
> <domain:hostObj>ns2.example.com</domain:hostObj>
> </domain:ns>
>
> You might perceive an ordering, there; that ordering is not a real
> one. That is, in formal terms, a set of nameservers. They are NOT
> ordered, as far as the DNS service is concerned.
>
> I'm sure you can find counterexamples; what that would establish is
> not that "order always has meaning" in XML, but rather that
> *sometimes* the order of elements in an XML document has meaning.

Or: Unless special care has been taken to take it out, order in a document has meaning.

> 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. Received on Mon Feb 27 2006 - 00:00:06 CET