Lists Home |
Date Index |
Ed Day wrote:
> Binary encodings don't have attributes, processing
> instructions, etc.. So how are we going to fire non-
> existent events? This does not make it any less SAX
However, ASN.1 X.694 defines encoding control notation
that allows the definer of a schema to say that when the
encoding format is XML, a certain element should be treated
as an attribute and the constraints on attributes should
apply (i.e. SIZE(0..1), etc.). I argue that if something is
marked to be an attribute when converted to XML, then it
should be marked as an attribute when it is passed through an
interface like SAX which is commonly used to process XML-like
data. If this were not the case, then binary data would look
different to the user of SAX when it was read directly via
SAX rather than being read from a chunk of XML written by the
XML encoder. This would be silly and unproductive.
Implementors of ASN.1 defined encodings who provide SAX
interfaces *MUST* ensure that the full richness of the XML
model is exposed to SAX in just the same way that it is
supported by the XML encoders. If you don't do this, then, to
get consistency, we will be forced to serialize the binary
streams to XML prior to passing them to SAX and we won't use
your SAX interface.
>This does not make it any less SAX compliant.
Of course, passing data without attributes doesn't make
the system any "less SAX compliant." However, it certainly
does end up in a result that it *not* what one would expect.
The encoding controls defined in X.694 are there to ensure
that ASN.1 defined binary encodings "look like" XML in all
contexts in which "looking like" XML is important. SAX is one
of those contexts. Thus, a SAX interface on such data streams
that did not pass attribute information for things which are
flagged as attributes in the schema should be considered
wrong, bad, not in the spirit of X.694, not useful, etc. even
if it otherwise appears to conform to the SAX interface.
Either do it right or don't do it at all. Please.