[
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.
len
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
|
