[
Lists Home |
Date Index |
Thread Index
]
Alaric B Snell wrote:
>
> 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.
This was an initial proposal for mixed content that was discarded during the
development of the EXTENDED-XER standard.
In the current text, mixed content is realized by including a "SEQUENCE OF
UTF8String" component as the first component of the sequence type and by
assigning an [EMBED-VALUES] XER encoding instruction to the sequence type
itself. When encoding in EXTENDED-XER, the items (strings) of the
"SEQUENCE OF" will be inserted before the first child element, between
consecutive child elements, and after the last child element.
Of course, when encoding in any other encoding rules, the "SEQUENCE OF"
will be encoded as a regular SEQUENCE OF - the "mixed content" concept is
specific to XML and is meaningless in BER, PER, etc.
Alessandro
>
> > 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
>
>
> -----------------------------------------------------------------
> 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>
|
