[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
>
>
> Bob Wyman wrote:
> >[most of the useful and helpful info snipped]
>
> Thanks. Very informative.
>
> > SET and SEQUENCE in ASN.1 are statements about the
> permited > lexical order of elements. In such cases that
> I've seen > significance given to order, it has been done in
> > specifications that accompany or incorporate the ASN.1 >
> definitions. However, the rules for Canonical and >
> Distinguished encoding both require that the elements of SETs
> > are, in fact, ordered according to their tag numbers.
> Thus, > any semantic significance of order would be
> discarded if SETs > were encoded with CER or DER.
>
> So SET can only be used with CER and DER when order is semantically
> insignificant. A case of performance trumping use cases,
> perhaps? (I'm
> thinking of John Cowan's astute observation that when lexical
> order is
> required order is usually not semantically significant, and
> when it is
> not required, order is usually significant.)
>
> > I'm not aware of any schema languages that allow the
> > specification semantic signifance to order independent of
> > lexical significance. Can you provide an example of one
> that > does? I am curious to see how this concept is used
> and > expressed.
>
> Right. Now we've come full circle. I began by saying that no schema
> language I'm aware of allows you to specify semantic significance
> (independent of lexical), even though it would be good
> documentation and
> useful for comparing XML documents.
Bob,
As I said yesterday,
**Roughly speaking**, WXS "sequence"s are mapped to ASN.1 SEQUENCEs, while
WXS "all"s are mapped to ASN.1 SEQUENCEs plus explicit information about the
order. The order is made a part of the abstract type definition and so is
made available to the ASN.1 application.
So, although ASN.1 lacks, per se, an equivalent of the WXS "all" model
group, the ability to specify semantic significance in XML encodings (which
means lexical "variable order", as opposed to "any order") is realized by
writing something like the following:
-------------
MyAll ::= [USE-ORDER] SEQUENCE {
order SEQUENCE OF ENUMERATED {a, b, c},
a INTEGER (1..1000),
b INTEGER (1..100),
c UTF8String }
-------------
This works as follows. The abstract value:
v1 MyAll ::= { order {b, c, a},
a 1000, b 70, c "hello" }
is encoded in XML as:
-------------
<v1>
<b>70</b>
<c>hello<c/>
<a>1000</a>
</v1>
-------------
The abstract value:
v2 MyAll ::= { order {c, a, b},
a 1000, b 70, c "hello" }
is encoded as:
-------------
<v2>
<c>hello<c/>
<a>1000</a>
<b>70</b>
</v2>
-------------
In this way, even if the constructor is SEQUENCE (and not "ALL"), the
information about the order is present in the abstract value, and is
therefore accessible by the application, both when writing and when reading
the abstract instance.
In other encoding rules the SEQUENCE OF ENUMERATED is encoded as a normal
SEQUENCE OF, because there is no requirement for the "lexical order" to be
implemented as physical lexical order. Notice that it is always the same
information, which may be "encoded" either as a physical order of child
elements (in XML), or explicitly as a SEQUENCE OF ENUMERATED (in other
encoding rules).
Alessandro
>
> Thanks again for taking the time to inform me and perhaps
> others on the
> ins and outs of ASN.1 SET and SEQUENCE.
>
> Bob Foster
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
