[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ASN.1 is an XML Schema Language (Fix those lists!) and Bin
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|