Lists Home |
Date Index |
more to the point you need more than xml, you must have a schema in xsd
but then a lot of discussion on this list is about validating xml so
that wouldn't be a big deal here.
which tends to not be in keeping with the postel's law thread.
personally i don't go in much for strict validation along the lines
lets you get good compression, but is a nuisance if you get someone
who's 101 - more common these days. and then you say ok
but when there's two orders of magnitude involved the probability of
valid, but inaccurate data goes up accordingly. 10 and 100 are both
valid but can easily be a typo and wrong. and who'd know?
but in the comms industry where asn.1 came from it's much easier to make
these assertions because eg current telephone numbers are 10 digits (in
this is a good start, but not a free lunch.
ps validation? if i do validation i do it against a dtd. throw away bad
documents and process the others. often though i accept anything and try
to make sense of it, only throwing it away if the parser fails.
On Wed, 2003-08-20 at 23:45, Bullard, Claude L (Len) wrote:
> Does this approach allow for variations in the
> algorithms for compression of numeric graphics data?
> From: Alessandro Triglia [mailto:firstname.lastname@example.org]
> Yes. The XML-Schema-to-ASN.1 translation standard you mention is X.694 (aka
> ISO/IEC 8825-5), currently at the end of its FCD ballot period in ISO.
> By applying X.694 to a schema, you get one or more ASN.1 modules that can
> produce binary encodings. These binary encodings are usually very fast and
> The translation from XML Schema to ASN.1 specified in X.694 is canonical
> with respect to all standard ASN.1 encoding rules. This means that two
> different implementations of X.694 will produce exactly the same binary
> encodings, thus enabling interworking without a need to distribute the ASN.1
> generated by the translation. In other words, the translation can be
> independently performed at each node and the nodes will interoperate in all
> The end result is that binary data, equivalent to a well-formed *and* valid
> instance (according to a source schema) can be exchanged, having an XML
> Schema available at both sides. This is one possible solution of the
> "binary infoset" problem.