[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Is Web 2.0 the new XML?

• To: 'Wolfgang Hoschek' <whoschek@l...>
• Subject: RE: Is Web 2.0 the new XML?
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Thu, 18 Aug 2005 15:58:28 -0500
• Cc: 'Michael Kay' <mike@s...>, xml-dev@l...

Ok, but let's differentiate scale and reach as 
we have here recently.   If I want to reach 
as many customers as possible I have two choices:

1.  Weaken the specification or standard to cover 
only the most common features as interpreted safely 
by each player (meaning, no critical semantic side effects as a 
result of local interpretations).  This is essentially 
the minimal victory strategy.  HTML works because it 
is mostly boxed formatting, the variations of actual 
rendering are minor and don't seriously impair the 
meaningfulness of the content.

2.  Create a highly customizable specification or 
standard with as many optional features as necessary. 
This is the approach that XML abjured but SGML embraced. 
It works but is costly (try to create a product for 
a single market that is actually a lot of little markets 
you have made one by abstraction rather than function). 
Given a complex product, however, this is the way to go 
until the market converges and complexity is subsumed 
in a commodity product.

I think if one is creating a standard, buy in is 
important but it is buy in among a select group 
of domain vendors who have a market.   If I am creating 
a specification, I want buy in among the likely implementors 
but also I want as many potential customers as possible because 
the goal is to create a market.  Unless you are certain 
of the customer base and have first mover advantages, run 
that one open as long as you are certain of success in 
getting it implemented.

In the first case, the problem is the vendors attempt 
to make the standard favorable to their product so they 
have the least to do for the most gain.  In the second 
case, someone will want to dominate the specification 
process if they have other advantages they can leverage 
to capture as much of the market as they can as it emerges. 

If the process is open, that can be seen.  If not, it 
can't.  No news there.   While I believe that standards 
processes should to the maximum extent possible be open, 
no such requirement exists for specification processes 
which by their very nature are disruptors.  That doesn't 
mean one should close them.  It means dealer chooses. 

This is why I emphasize leadership experience:

Open standards processes with too many non-market 
players can fritter away a lot of time and energy.  On the 
other hand, if one closes the processes and there is a 
lot of customer interest, they will open up elsewhere 
and you will be shut out.  That is exactly what has 
happened to my company.  We have been very slow about 
blogs and open communications, so our customers formed 
their own Yahoo users board for their own  
community.  They purposefully exclude the vendor. 

That's one of the lessons the MBAs should learn 
and right fast about the web.   It doesn't just route 
around one; it builds a wall around what doesn't work 
with it in a mode of trust exactly like an ecosystem. 
It isolates non-cooperators; it doesn't kill them but 
they may suffocate.

The problem of openness is the tacit assumption that 
only one game is in play.  In fact, today multiple 
true and faux standards and specs organizations are 
attempting to organize the same markets with varying 
successes.  This is when it doesn't come down to 
the 'smart people' or even the 'right people'. It 
can come down to who can hold their breath the 
longest.  The 3D market is a splendid example of this. 
The money in 3D is in games and that is where standards 
are least likely to take hold and specifications proliferate 
like park pigeons.   A standard must have a substantial 
and clear  payback or it won't thrive.  A 
specification is, well, speculative, so as in music, 
a gambler's game.

len


From: Wolfgang Hoschek [mailto:whoschek@l...]

It appears that "scale" aka "organizational size" is at the heart of  
the problem.

A spec process for a small audience is easier to manage than one for  
a large audience including all the heavy weights. Having more  
participants means having more differences wrt. perspectives,  
backgrounds, priorities, timelines, strategies, policies, etc.

Getting broad buy in and rough consensus before having running code  
makes it more likely agreements and a spec will eventually emerge,  
though it unfortunately also increases the odds for a spec that may  
be bloated, fuzzy and ultimately of dubious quality and merits. On  
the other hand, having running code first implicitly puts someone  
into a dominant riding seat, and while it increases the odds for a  
focussed quality spec, it reduces the odds for broad consensus across  
many heavy weights. It's a difficult chicken and egg problem.  
Ideally, the "running code" and consensus building process would go  
hand in hand in parallel at multiple participants, and inform each  
other continously. But that's easier said than done when working "at  
scale".

Wolfgang.

• Prev by Date: Re: Is Web 2.0 the new XML?
• Next by Date: Re: WORD TO XML/SGML
• Previous by thread: RE: Is Web 2.0 the new XML?
• Next by thread: RE: Is Web 2.0 the new XML?
• Index(es):
  • Date
  • Thread