[
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?
Of course - mixed content just means that strings can pop up between
elements. In the ASN.1 abstract type that's just some extra string
fields, and an annotation to say that they are mixed text rather than
elements containing text.
> I 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. If it can, some advocacy, and
> especially demonstrations of what concrete advantages ASN.1 might offer
> in specific circumstances would help spread the word.
Sure it can.
Document ::= SEQUENCE {
title BMPString,
sections SEQUENCE OF Section
}
Section ::= SEQUENCE {
title BMPString,
text SEQUENCE OF Paragraph,
subsections SEQUENCE OF Section
}
Paragraph ::= Text
Text ::= SEQUENCE OF CHOICE {
text UTF8String,
bold Text,
italic Text,
hyperlink Hyperlink
}
Hyperlink ::= SEQUENCE {
url AnyURI,
anchor Text
}
I can't remember the annotation to say that the 'text' option of the
'Text' type is to be represented as mixed content:
<Paragraph>Hello world</Paragraph>
rather than:
<Paragraph><text>Hello world</text></Paragraph>
...since I've been out of the loop lately.
> Given that ASN.1 is now capable of fully describing XML objects, it
> should be included in all lists of "XML schema languages." And, we
> should put to bed the now mute discussion of "Binary XML." XML
> should stay in the realm it started in -- a text-based language for
> tagged data exchange. The problem of binary exchange is handled well
> by others...
>
> 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?
No... ASN.1 is a schema language for abstract data models ("A person has
a Name which is a String, and an Age which is an Integer..."). As a
seperate-but-related thing, there are 'encodings' which are
representations of instances of that abstract model (The person with
name 'Alaric' and age '24' is represented as 010100101001010010010...).
Most of those encodings are not layered on top of text encodings like
ASCII or Unicode, so can be considered 'binary' (although this is a
potentially confusing term that I try to avoid...), but that doesn't
mean "ASN.1 is binary"; after all, with the XML encoding rules, there is
a very definitely textual encoding available.
The advantages of having several different encodings all using the same
schema system are:
1) Less to learn. Why do we really *need* different schema languages for
different notational systems? The only argument is that different
notations can represent different value spaces, but most of them can
handle a significant common subset, so one could have a universal schema
language with 'pragmas' for specific encodings that can be ignored by
other encodings, as has been done with the XML encoding.
2) Interoperability between encodings. Without human intervention, it is
possible to transcode arbitrary messages between any ASN.1 encoding
ruleset; the software just decodes using one set of rules and then
encodes with another.
3) Flexibility of encoding. Given a system whose communication is
specified in terms of ASN.1, it is easy to use different encodings at
different points. For archival storage, use BER (basic encoding, simple
to describe and contains redundant metadata) with a copy of the schema
prepended. For communicating and short-term storage, use PER (packed
encoding, very space and time efficient). For interoperability with the
Web, use XER (XML encoding). But the software remains the same no matter
what encoding is being used for reading and writing - your code says,
"Get me the Name of this Person object" and the pluggable encoding
module loaded from the libary handles the specifics for the encoding in
use. This gets away from a certain balkanisation that occurs sometimes
in software projects: "Well, we can base our system's data model around
XML which will make the display onto the Web easy because we can use
XSLT, but it means that the coupling to the business logic will have to
hand-pick through the messages with XPath - or we could use CORBA, which
will provide direct and transparent mapping of the messages to objects
in whatever languages we code in, but will make the Web interfacing
harder".
ABS
|
