Gates on XML & other stuff

[Len Bullard]

Tim Bray wrote:
> 
>   http://www.informationweek.com/762/gates.htm
> 
> The XML stuff is in sections 3 & 4, but it's all worth reading. -T.

Interesting.  Gates discovers the science of logistics.  Good.  

"CEOs should have a notebook full of every paper form in the company and
an explanation of what the
 plan is to get rid of that form. He doesn't have to understand
technology.."

True.  At the CEO level.  Below that, beware.  Good e-comm engineering
even 
with standard components still requires something akin to standard
systems 
methods.  It is still a transform to the new system and in that, the
reliability 
measures determine how much information is preserved.   The issue going
in is 
how much information is worth preserving, and that starts the fight. 
Without a 
method and means to declare closure, it is a business process that lasts
too long.
By the time one gets it done, the opportunity to use it passes. 
Synchronizing 
the process and events of multiple teams becomes a game of crack the
whip.  Some 
of the teams get it; others are overcome by it because the binding order
favors 
the teams with resources and will to convert.  So, the method must
divide the 
initialization of the base policy set from the negotation of the
contracted 
peformance.  In easy terms, screenwriters then actors.

He states then:

"We don't know how to run a communication company. We don't do that.
We're just 
partners and supporters of the people who are going to make those big
investments."

Scary.  The markup approach is communications:  negotation of contract.  
Declare the goal of the negotiation, then agree on the event schedule
and 
the types.  However, if you need a method, beware the "spinkle tags
through 
documents".  To be efficient, negotiated types require external
agreement and 
sprinkling tags is not how one achieves that.  It is a way some learn
how tags w
ork, but ultimately, rock solid and legally binding contract
negotiations require 
predesigned types.   These are the libraries.  The lag time is the time
to 
convert to these.   That will take a while and is a stone of sysyphus
really. 
But, Sysyphus is paid to keep rocking; he grows a ponytail and becomes
Cousin IT. 

"There's going to be so many standards, so how do you map from one XML
schema 
to another schema?"

BizTalk is what that is but only in that BizTalk is a repository.  So 
is OASIS or any other language services server.  Automated negotiation 
services is the logical evolution of that.

The methods of negotiation based on the goal requirements are the means 
to premap XML schemas.  Agree in advance which preformed types
aggregate, 
in what order, and sometimes, frequency and range.

"It's not just records but it's the whole process and the events in 
that process. How do you build products and standards that digitize
that?"

You're not killing Cousin IT.  You provide products so Cousin IT can do
what he does
better.  You make is such that the tools the other professionals use
are easily integrated to the servers the ITs are setting up.  

Pre-aggregate.  An early negotiation in the business process is engaging
the 
notations to be used at each step of the process, that is, which events
call 
which notations.  Declare the valid namespaces for that document.  In
DTDs, 
one declared a list of notations and data attributes for notations.  We
threw that away 
in XML.  Turn's out, we need them.  Notations let you declare the
component, 
any standard values to pass, and gave you a name for referring to the
process. 

A system where the components map to standard notations (in the long
run, 
any XML application languages is just a notation) requires the ability
to 
test conformance.   Otherwise, there is no meaningful definition of 
reliability MTBF (Mean Time Between Failure).

"Making your business ready for the Internet--that involves security,
exchanging
documents externally, policy-based management. Reliability... it's
probably
the one that drives the sales the most...Reliability is a statistical
phenomenon.."

Reliability has to declared at the component/notation handler level.  
Microsoft's 
biggest drawback is dll management.  It is where the system is hardest
to 
field and share.  Anyone dealing with forms that cache GUIDs sees this
quickly. 
XML can't fix that except to say, if the notation is a PUBLIC notation, 
the user can get another object.  It must interoperate in the
framework.  
Microsoft's challenge is to ensure that interoperation of conformant 
components.... regardless of who declares the namespace in the file. 
The PUBLIC id is the signature of the information.   You agree to 
reliably process information so signed.

To succeed in this, Microsoft needs more than XML.  XML doesn't work 
unless component-level reliability is ensured.  That is what we 
contract for.  The vendor who can get higher reliability ratings 
gets the disk space.   Again, XMLs only real advantage is that from
packet  
to purse, it all goes easier if the parse is common.

len bullard
intergraph public safety



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)