RE: [xml-dev] Word 2003 schemas available

["Michael Rys" <mrys@microsoft.com>]

If you are concerned about interoperability in loosely-coupled systems,
then more than one interop format is bad. I define the scenario as: I
publish information, that is being used by applications that I have no
knowledge and control over and applications operate on data from sources
that they do not know and have little control over (except for coaxing
them to provide some data) without having to perform lots of apriori,
high-level negotiations.

If you start having more than one format available, then you start to
have to support more than one format on both the client and the server,
start to have some negotiation protocol to say, what format you prefer
etc. If you only have one format, then this becomes much simpler, and in
my opinion often more efficient.

Also note that at least communication overhead in distributed
environments can be addressed by lower level compression formats "on the
wire" such as MNP-5 that are transparent to the transported XML.

To address your cases:

1. Real time 3D: Do you really consider this a loosely-coupled scenario?
It depends. If you can live with network latencies etc, it may well
loosely-coupled. However, in that case, the XML on the wire is a small
part of the cost. If you want to repurpose VRML for other uses than real
time 3D, you should be happy about the use of XML and see it as a
trade-off. Also without knowing what they consider the speed bottleneck
and the general scenarios beyond VRML, it may be that a binary format
just doing real time 3D may be better than XML. But I have a feeling
that the real perf issue is not the parsing of the XML, but the general
transport latency...

2. No. XAML is using the XML representation to be interoperable and
usable in a loosely-coupled scenario. The application that compiles XAML
into a UI is only one application. You could potentially use the XAML
format for totally different purposes (like transforming it into another
XML markup that does the same or something different). The compilation
aspect is not part of the discussion about using "binary XML" vs true
XML.

3. See above. In addition, couplings that are more tight normally tend
to be based on a controlled environment where specific additional
protocols exist to exchange information. In those contexts, it may make
sense to use some scenario specific binary encoding. 

For example, a database server that serves XML through a variety of DB
APIs may decide that it off-loads some of the serialization of the XML
to the API layer (or even only expose a reader interface). In that case,
if the client communicates that it understands the binary format
provided by the server in some way or the server says, if you are API X
I trust you to understand the binary format, then you use binary format,
but otherwise I give you the textual XML. However, this is a
tightly-coupled system since the server and clients know each other, the
user of the API still sees only the XML and the binary format is
optimized for this scenario (which may not work in another scenario).

Best regards
Michael
 
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Tuesday, November 18, 2003 10:25 AM
> To: Michael Rys
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Word 2003 schemas available
> 
> Michael:
> 
> I agree with much of that, but it flies in the face of
> experience in some cases.
> 
> 1.  Real time 3D:  it needs performance and it needs
> an addressing strategy into the performant format.
> VRML customers demand a binary.   Is that a closed
> system?
> 
> 2.  XAML has to be compiled to run fast.  Is that a
> closed system?
> 
> 3.  What do you mean by 'interoperability' and how
> does it relate to coupling strategies?
> 
> The rules of thumb for coupling databases and performant
> rich clients aren't the same.  Comments?
> 
> len
> 
> 
> From: Michael Rys [mailto:mrys@microsoft.com]
> 
> [Michael Rys] You mean like the format used in the .doc files? :-)
> 
> Binary XML in my opinion flies in the face of loosely-coupled
> interoperability. By adding a "standard" binary XML format (be it
based
> on ASN PER/BER or some other scheme) the interoperability gets
> bifurcated and the advantage of a single, auditable, interoperable
> format to be used in loosely-coupled environments disappears. In
> closely-coupled systems, you can use something else than XML (or a
> binary format). Since the coupling is closed, you do not need to
follow
> a standard (although there are some reasons why you still may use
XML).
>