Lists Home |
Date Index |
Bob Foster wrote:
> On another point, you have said a couple of times that ASN.1 doesn't
> provide anything like XSD's 'all'.
I was referring to the notation for defining types.
ASN.1 doesn't have a corresponding keyword or construct. While there are
SEQUENCE and SET, there is no ALL.
> > So, although ASN.1 lacks, per se, an equivalent of the WXS
> "all" model > group...
> Why do you say that? Is it just a matter of notation? 'all' isn't
> anything but a variable-order sequence with possibly optional
To support variable-order sequences in XML (corresponding to WXS's all), the
XER encoding instruction [USE-ORDER] has been introduced. Encoding
instructions operate at a different level than the basic notation - they
only alter the encodings, without changing the meaning of the abstract type
The effect of [USE-ORDER] is (as I showed in a previous email) to alter
the XML encoding of a SEQUENCE type so that its first component (a SEQUENCE
OF ENUMERATOR) determines the order in which the other components appear in
the XML. The first component is not encoded as an element, but as the
*order* of the elements into which the other components are encoded.
The SEQUENCE can have optional components, of course.
> Is it that the ASN.1 corollaries don't allow optional elements?
> I can see why ASN.1 might not offer the equivalent of RELAX
> NG's shuffle
> (which it calls interleave) or SGML's variable-order sequence with
> optional and repeating elements (which it calls interleave), but not
> little old 'all'.
The reason why ASN.1 does not have an "ALL" constructor is the fact that
this constructor (unlike SET, which operates at the abstract level) would be
meaningful for human-readable encodings (such as XML), but useless for PER
and BER. The ability to use "physical" order of components in PER or BER to
convey some meaning is not useful, given that you can represent the same
meaning in other ways, and humans are not normally exposed to the "physical"
order in PER/BER encodings.
> Bob Foster