RE: [xml-dev] Word 2003 schemas available

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

See inline below. I am not sure we really disagree to a deep extend, but
here it is anyway :-)

Best regards
Michael

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Tuesday, November 18, 2003 11:59 AM
> To: Michael Rys
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Word 2003 schemas available
> 
> Short form:  some applications need a binary.  The
> may not need XML and may not benefit adequately from
> a binary form of true XML, but since they choose XML
> and they need a binary, they may not get what they
> need from XML specifications and will pursue independent
> development anyway.  Control should only be applied
> where control is useful and that is my input to the
> W3C binary interoperability group.  Don't develop what
> won't be specifically useful if it won't be generally used.

[Michael Rys] I think I agree. And since my premise is that a single
binary format is not generally useful in an open interop scenario, I
feel they should not develop anything...

> len
> 
> Long form follows:
> 
> From: Michael Rys [mailto: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.
> 
> My problem with that definition is that it ignores certain facts.  A
> format handler needs to be predictable; otherwise, how would I know
> which one to buy?  So an HTML handler renders HTML and can do it
> loosely, but the market doesn't like that and spent a lot of resources
> trying to lock down the presentation through extended means such as
> CSS, and in many cases, simply surrendered to IE.  This is not a
critique
> of IE; it is just an obvious fact.  In the case of VRML, failing to
> get rendering and behavioral fidelity (and these are not the same),
> caused the same behavior in the market.  Eventually Cosmo dominated
> although the market collapsed.  With X3D, the designers learned their
> lesson and created a standard based on the abstract object model
> and then and only then the encodings.  In effect, for some classes
> of application, loose coupling is a myth.  What is not known and
> is not effectively knowable is what is supported by a given platform
> at a given location when a user at that location selects a page to
> download.  XML didn't solve that problem and can't.

[Michael Rys] XML does not solve this problem. But it enables
repurposing of data in new ways, which HTML, due to its limit semantic
richness did not do a good job. Obviously, you can define XML
vocabularies that are better suited or less suited for repurposing.

> >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.
> 
> Simpler yes, but efficiency is a local politic controlled, in some
cases
> by a local policy.  In short, it varies by application.  There is not
> an efficient one size fits all, just a one size fits most even if not
> comfortably, somewhat like the old Russian fashion show commercial.
> 
> It can be more efficient but the application designer is not relieved
> of the creation of the abstract object model particularly if the
> handler has both dimensions of rendering and behavioral fidelity.

[Michael Rys] The problem is that if you start to need to support
tightly-coupled negotiation protocols to figure out what format you have
to send/you are getting, you add complexity. As you do if you have more
than one inter-op format.

I fear that splitting the interop story of XML into a textual and
Infoset-based/binary representation, we are going to get the "divide and
conquer" effect that in the end will make XML just another ASN.1: a
niche model that does not deliver the interop it promises and we will be
back to lock-in.

> >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.
> 
> Noted in the early VRML debates on binaries some years ago that
settled
> on gzip because it was the sweet spot at that time, or so we thought
until
> the customers began to rally for a binary.
> 
> >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.
> 
> Network latencies are only a big problem for updates in shared worlds.
> Even for monoworlds, the size of the VRML/X3D file is mostly the
textures
> and these have
> to be cached in local libraries (eg, Universal Media) or downloaded.
> For that reason, X3D and others have a "Start when loaded" feature.
> XML isn't the problem as you note, nor is it much advantage.  It adds
> size but since the infoset abstraction isn't part of the X3D
> specification,
> not much else.  Even editor support is dicey because graphics editors
> rely on hand to eye identification and recognition.  It is a touch
> and feel art similar to layout in a page renderer, but much more
> complicated.
> 
> >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.
> 
> Can and do.  Repurposing is dodgy though when a format includes
> behaviors.  Thus the MID.  Thus XAML.  VRML/X3D mixes behaviors
> into the client language and for real time, that is essential.
> I think if anyone starts attempting to make libraries of repurposable
> XAML, they'll encounter similar issues.
> 
> >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...
> 
> It isn't the parsing typically.  The problems of real time 3D are
> in synchronization in a multi-player model of operation, and keeping
> rendering rates around 15fps in the low range, and at least 30 at
> the sweet spot.  Consider that real time 3D simulation has to
> preserve the 'reality paradigm' in games, so loading bits into
> and out of the scene without breaking the action to resync all
> of the clients is a bear.  Think of the scenes in the Matrix
> where they freeze the action so the machine can catch up to
> the human's unpredictable actions.  So one gets speed wherever
> one can find it and the parsing is not offlimits, but is as
> you say, a tradeoff.
> 
> >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.
> 
> Interesting and noted.  That was the MID reasoning as well, but
> compilation
> for performance was required.  Interpreting MID and I assume XAML, is
a
> non-starter outside the editing suite.
> 
> >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.
> 
> See response above.  I think you are being disingenuous.  One can
> disregard
> these considerations precisely because the controls have already
emerged
> in the forms of standards and specifications apriori.  It is the
> non-standard
> use or reuse that your description applies to.  XML is a hedge against
> uncertainty.
> 
> >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).
> 
> Note that you are dropping down a scale dimension or two for your
> example.  Client/server != web client/web service.  I'm not sure
> the same is true above the scale of the local system.  In fact,
> the more one is loosely coupled, I think the more one has to be
> negotiating.  It is just the humans who are negotiating offline
> and the machine therefore, can blithely be unaware.

[Michael Rys] I dropped down since on that level, you are really not
loosely-coupled anymore. On the higher-level, you want to have
negotiation on the semantic level and share the syntax and not have
syntax negotiation as well.

> Thanks Michael!
> 
> len