[
Lists Home |
Date Index |
Thread Index
]
Robin Berjon [mailto:robin.berjon@expway.fr]
>
> Bob Wyman wrote:
> > Robin Berjon wrote:
> >>There's a lot to say in favour of minimizing the
> >>number of concrete syntaxes, and that's where a
> >>lot of the concerns about having *two* (just two!)
> >>universal formats came from at the binary infosets
> >>workshop.
> >
> > The number of syntaxes isn't important. The only
> important question
> > is: "Can two systems interoperate?"
>
> Obviously, interoperability is at the heart of the matter. But it is
> much easier to interoperate with a single concrete syntax
> than with ten.
> Lesser complexity, little or no negotiation.
>
> > Well, even if there are
> > hundreds of alternative syntaxes, you can always answer
> "Yes" to that
> > question by simply making a rule: "Text-based XML must always be
> > supported. All other encodings are optional." This allows "Dual
> > encoding" systems (systems that support both text-based XML
> and binary
> > encodings to interoperate with *any* other system.
>
> This was also suggested at the workshop, but fails to work in cases
> where the reason XML doesn't work is because of its footprint (or
> sometimes other issues such as performance that cannot drop below a
> given threshold). In those cases you can't reasonably ask people to
> support XML 1.x, and if you do they won't listen.
That is what usually happens with ASN.1. Standard specifying ASN.1-based
protocols usually select one set of encoding rules. Implementations need
not include encoder/decoder libraries for encoding rules that are not used
by the protocol.
>
> Also, it won't work for unidirectional networks. If you
> broadcast using
> an optional encoding that I don't support, you'll never know about it
> and the broadcast will fail. Using XML 1.x in such situations
> is rarely
> an option. Negotiation only works when one can negotiate.
I agree.
>
> Goal 5, amongst other things stated before in this thread,
> has helped XML
>
> 5. The number of optional features in XML is to be kept to the
> absolute minimum, ideally zero.
> -- http://www.w3.org/TR/REC-xml#sec-origin-goals
>
> Options do tend to get in the way of interoperability.
>
> >>The ASN.1 equivalent of a simple XML parser in terms of
> >>universality would have to properly decode (and likely
> >>handle negotiation for) BER, PER, CER, DER, XER, and
> >>probably LWER, OER, and SER. That's a bit of a
> >>behemoth to implement!
> >
> > It may be hard to implement, however, it has been done
> -- at least
> > for BER, PER, CER, DER, XER, CXER, and E-XER... At least by the
> > commercial suppliers like OSS Nokalva.
>
> Is it possible to reliably auto-detect which ER is being used?
I will read this as an academic question, as I don't consider it as sane
practice to rely on automatic detection of the encodings.
In theory, the answer is "not always".
In practice, you can, 99.9999% of the time, easily distinguish BER from PER
and XER if you know the schema.
CER and DER are just canonicalizations of BER, therefore a BER decoder will
decode any CER/DER encoding without even realizing it is a CER/DER encoding.
It may be more difficult to distinguish between the "aligned" variant of PER
and the "unaligned" variant of it. (Why do both exist? Historical reasons.
There were users who wanted both. "Unaligned" PER aims at extreme
compactness, although this has usually the undesirable effect of making the
encodings harder to compress. In general, compressed aligned PER is smaller
than compressed unaligned PER.)
Canonical PER is just a canonicalization of PER. Like BER/DER/CER, a
non-canonical PER decoder will decode any PER, canonical or not.
As for ECN, given that it requires a separate module for specifying the
custom encoding rules, it poses totally different challenges, so nobody
would expect to be able to autodetect it!
As you can see, the situation is not so bad after all. There aren't that
many options... The number is quite reasonable if you consider that ASN.1
is 20 years old.
>
> > Yes, building an
> > open source equivelant would be a challenge... But, it is just a
> > question of being "hard."
>
> A SMOP? ;)
>
> > At least there aren't any patent issues like
> > there are with something like "binXML" or the other binary
> encodings
> > people are inventing these days.
>
> Do you have specific examples or are you saying that everyone except
> X.694 is encumbered? Has ISO/ITU-T performed patent searches covering
> X.694? It was brought to my attention as I used that very
> same argument
> that X.694 was in fact covered by some patents :(
Really? I am one of those who have developed X.694, but don't know about
any patent covering it. Is there something I should know but don't know?
Alessandro
>
> --
> Robin Berjon <robin.berjon@expway.fr>
> Research Scientist, Expway http://expway.com/
> 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
>
>
> -----------------------------------------------------------------
> 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>
|
