RE: [xml-dev] Comparison of Xml documents

["Bob Wyman" <bob@wyman.us>]

Alaric B Snell wrote:
> in ASN.1 you can specify if order is important within a 
> compound object - if order matters it's a SEQUENCE, 
> otherwise it's a SET :-)
    Alaric, you may be overstating the case for ASN.1 here. There are
two kinds of ordering discussed in Pierre Garnier's message. I think
ASN.1 only handles one of them which is clearly the one you mentioned,
however, some folk might think you also meant the other.
    In ASN.1 you can specify that things are either a SEQUENCE or a
SET. Elements within a SEQUENCE are ordered while elements within a
SET are not. Thus, given:

    ordered ::= SEQUENCE {
       part1 INTEGER,
       part2 INTEGER
    }

   Your XML encoding could be:
    <ordered>
      <part1>1111</part1>
      <part2>2222</part2>
    </ordered>

   But, the following would be illegal since part2 comes before part1:
    <ordered>
      <part2>2222</part2>
      <part1>1111</part1>
    </ordered>

    If you want to be able to provide part1 and part2 in either order,
you would define a SET instead. You would write:
    ordered ::= SET {
       part1 INTEGER,
       part2 INTEGER
    }

	But this is only one kind of ordering mentioned in Pierre's
message. This is ordering of the structural elements of a message. I
think he also wants to have elements ordered according to their
values. Thus, if you allowed multiple "part1"s to appear in a SEQUENCE
or SET, the question is which should come first? Pierre seems to
indicate that he wants the order determined by the value of instances
of the elements -- not by their types. i.e. he wants to permit:
    <ordered>
      <part>111</part>
      <part>222</part>
    </ordered>

   while prohibiting:
    <ordered>
      <part>222</part>
      <part>111</part>
    </ordered>

    I don't think ASN.1 supports this kind of constraint in the
standard syntax. Or, have I missed something in the spec?

		bob wyman