OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: Why a "general" solution? (was: RE: [xml-dev] XML Binary Characteriz

[ Lists Home | Date Index | Thread Index ]

1. Interop is system to system.   The web is not one 
system.  It is a federation of systems.  Not all of 
them interoperate.  I am not afraid of solutions 
in the wild if they solve wild problems.  I am 
very much afraid of solutions in the normative 
sense that only weakly address specific problems.

2.  Best practices are captured but must also be 
applied where applicable, not in general.

3.  Reuse of solutions is available as applicable.

4.  XML can be improved, but I don't believe an 
alternative format or encoding does that.  It 
offers alternatives to XML that can be processed 
by some XML systems.  Because our definitions for 
XML systems are weak and not always consonant, 
we don't have the clarity needed.  Because 
applications and application languages differ 
(eg, XML Schema), we can only improve them on 
a case by case basis.

The current basis for XML-system wide interoperability 
is XML 1.0 and 1.1.  If we add a generalized binary 
encoding, there are no guarantees that we will improve 
interoperability; we might in fact, more than double 
our chances of compromising that. Or worse. Today, X3D 
has both the XML encoding and the VRML Classic 
encoding with the implicit requirement to support 
VRML97.  Tim Bray and I both predicted there would 
be problems with that, and unfortunately, we were 
right.  As we add an X3D binary, I expect these to 
get worse.  I would hate to see 
such problems go XML language space-wide.  Seems like 
an awful lot of pain if the payoffs aren't ten fold.

If we follow this to a logical conclusion, I think
we will end up with a binary-design toolkit, not 
a single binary. 


From: Bob Wyman [mailto:bob@wyman.us]

Claude L Bullard wrote:
> The case is made for some applications using a binary.
> The case is not made for it being generalized.

	We should address the general issue of binary alternative in
order to:
	1. Ensure and encourage interop
	2. To allow capturing "best practices"
	2. Permit and encourage reuse of solutions
	3. Improve XML, XML Schema, etc.

	The highest priority should be to encourage interop. Today,
people who are driven to a binary format (for whatever reason) are
left to their own devices and have little guidance concerning the
quality of XML alternatives or what may be best practices for using
them. We can't prevent binary solutions from being used. What we
should do is whatever is necessary to ensure that those binary
solutions don't compromise interop.
	For instance, this thread has raised a number of issues or
dangers concerning binary formats. There is a concern that conversion
of floating types might cause damage or that signatures might be
invalidated on conversion to binary. Thus, what we need is a document
that can say things like: 
	1. Beware of certain type conversions. Watch for pattern
facets, etc. that may require preservation of lexical elements such as
leading and trailing zeros or leading "+". 
	2.  When handling a signed XML document or element, use
X.finfo, not X.fws, in order to ensure that it can be faithfully
reconstruction of the signed content."
	3. etc...

	It would be massively more useful if the current statements
such as: "Don't use an alternative since it might cause problem X."
were reworded to say: "If you use an alternative, ensure that X does
not occur." Capturing this guidance would be generally useful no
matter which binary format is used or even if the alternative format
is, like XML, text based.
	It should also be noted that if the XML community actually
faces seriously the issues of interop with alternatives, we might
discover or highlight some areas of XML that are underspecified or
that could be improved. For instance, providing an easier to use
mechanism for specifying which optional lexical elements of numberic
types need be preserved might improve XML interop independent of any
consideration of binary alternatives.

		bob wyman


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS