[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
>
> "Just about any XML object" may be the operative phrase here.
> Can ASN.1 systems handle mixed content and open content
> models, e.g. XHTML?
Yes. When translating from XML Schema to ASN.1 using X.694, the resulting
ASN.1 has roughly the same ability to "describe" a class of XML documents as
the original schema.
("Roughly" here means that ASN.1 lacks some minor features such as
identity-constraint definitions. On the other hand, ASN.1 has extra
features that don't correspond to anything in XML Schema.)
Mixed content is supported.
Content-model wildcards and attribute wildcards are supported (including the
namespace constraint).
Unions are fully supported (including the use of the "xsi:type" attribute to
identify the chosen member).
Type-derivation hierarchies are supported (including the use of the
"xsi:type" attribute to identify the type being used).
Nillability is supported (including the use of the xsi:nil attribute).
Element-substitution groups are supported (including the exclusion of
"abstract" element declarations).
The "all" model group is supported (the order used in instances is
explicitly represented in ASN.1, because this information may be meaningful
to the reader in some cases).
> was under the impression that ASN.1
> could model strongly typed, regularly structured XML but
> haven't heard anyone advocate it for more content-oriented,
> document-like uses.
See above. Apart from identity constraints, there is *very* little of XML
Schema that is not supported in ASN.1 and gets lost in the X.694 mapping.
In addition, if you use ASN.1 directly (as opposed to mapping from XML
Schema), there are many other features available, such as a richer set of
subtype constraints.
> Now I'm confused: If ASN.1 is an "XML" technology, isn't it a
> "binary XML" system, that is, an alternative Infoset with a
> range of possible serialization formats?
One of the main characteristics of ASN.1 is its emphasis on the "abstract
value" as distinct from the "encoding". The type definitions are not
thought of as describing (or constraining) documents in external syntax (as
in other schema languages), but are thought of as defining sets of abstract
values. In ASN.1, there is a duality "abstract syntax" / "abstract value"
on one side, and another duality "abstract value" / "encoding" on another
side. An (abstract) value is one of the values of an (abstract) type, and
this is completely independent of any possible external representation (as
bits, bytes, or Unicode characters) of the value. In ASN.1, you fully
define a data structure in abstract terms (i.e., with no regard of the
external representation that will be used for interchange). So there is no
"infoset" in ASN.1. There is the set of (abstract) values of an (abstract)
type, which can be represented (transmitted, stored) in any of the standard
available encodings: PER (binary), BER (binary), ..., or XER (XML).
In other words, when you have an ASN.1 type definition for an XML document
element, you can "decode" the XML element and get an "abstract value" for
that element. You can then re-encode that abstract value using any other
standard encoding rules (such as PER). The abstract value is one of the
values of the type. Unlike an element information item in an infoset, an
abstract value cannot exist without the type of which it is a value.
Alessandro Triglia
|
