Musing over Namespaces

[Len Bullard]

Dan Brickley wrote:
> 
> I didn't take Tim to be arguing against decentralisation, but against
> the multitude of companies/organisations who both promote the
> centralised monolithic (meta)data registry approach, and
> (coincidentally) attempt to promote themselves as providing that
> service.

I guess that includes OASIS.  Too bad.  It has a chance of 
being a significant organization in this.  I've really no 
objection to ANY company selling such a service.  I can 
think of many small companies for which it may be useful 
in the same sense as bookies are to horse races but when 
you look at the models for contracting used for very large 
transactions, it is much more useful if each B2B interface 
is established dynamically.  Otherwise, faster simply means 
less quality.  Review the decline of the airline industry 
services as they reach saturation.  But my point is, if there 
is going to be one, we are better served if there are lots 
of them.  Caveat Emptor.  If OASIS wants to do it, I certainly
hope MS does, and Sun does, and MaAndPaRegistry do too.

The real product by which ecom-ecologies will be judged is the 
quality of the experience both in getting the product 
and in using the product.  Quality is coupled to profit.  
As the profits become razor thin, the quality declines. 
Faster, better, cheaper:  pick any two.
 
> One of the supposed big wins of using the same syntax/model for our
> meta-languages and our instance data is re-use, synergy.

Yes.  I am aware.  See the experience of the CALS community with 
this and in fact, the entire history of markup since type definitions 
were added to the original generic coding designs.  Most attempts at
centralization  failed.  

I don't think it was the fault of the registry designers 
or anything sinister.  It has to do with defining and maintaining 
visible and hidden definitions of processes which preserve profit.  

So, reuse is cool but not the goal, just an optimization.  If the 
effect of B2B and B2Customer is to suck out the local profit (think 
for example, sales tax), the result is the destabilization of the 
local ecologies just as super malls killed downtowns.  Except in this 
case, China Kills California.   It happens fast.  I suspect some 
weird and typically badly informed debates are going on at high 
levels of governments worldwide.  I predict higher property taxes 
but anyway, the point is, the local system declares its own 
namespace, declares what is visible, and contracts for tests 
of quality performance and deliverable. 

It's called Logistics.  Originally CALS was Computer-Aided Logistics 
before it became Commerce At Light Speed.  The WebSters are about 
to repeat the same mistake made by the CALS groups when they chose to 
take a bridge too far.

> Eg. if RDF and XML vocabularies are themselves described using RDF and
> XML, then generic discovery/indexing/trust systems applicable to _all_
> XML/RDF content should be equally applicable to schemas.

The fate of RDF is irrelevant.  It is a means.  I think the topic 
map folks already had most of this ground covered but that is a means 
too.  It does have some interesting running code to back it up.

> Why then
> promote centralised registries for all schemas? Surely there will be
> search engines and 'trusted third parties' for schema data, as there
> will be for other applications of XML and RDF.

Surely.  Now what will they do with that namespace?  What is it useful 
for other than as David is pointing out in the sibling thread,
packaging? 

> By defining schema
> languages in instance syntax, we implicitly promote the idea that there
> will be some big payoff for doing so (otherwise, lets stick with
> DTDs). 

There is some payoff:

1.  Political.  XML can finally dissolve the XML to SGML parentage.
2.  Technically.  It is a stronger schema model. 

There are some downsides too:

1.  Politically.  It is absurdly complicated to explain.  It needs 
so many names to name the names, it vindicates the Hytime work 
completely.

2.  It is limited unnecessarily.  I have to go back an look, but 
unless arrays have been added it is incomplete.  Even if one 
can simulate that in the application language, the experience has 
been when the implementors have to do an unreasonable amount of 
work to get the same results as familiar means, they opt for 
familiar means or they adapt and create similar means which 
they make more useful in their own application. 

In other words, it may be the case that schemas aren't the 
best or only means and may not become the preferred means. 
A lot depends on how other language communities perceive them 
and other economic ecologies provide alternatives.

> Some synergy that means generic tools will be applicable to
> schemata. I find this impossible to reconcile with the
> www.really-important-trusted-metaregistry.[com|org] approach that seems
> popular in the industry. I'm banking on doing schema searches at the
> mainstream search engines in 2-3 years time...

Yes.  It concerns me if the community of XML developers are not yet 
recognizing that.  OTOH, if you do, you are ahead so Get It While 
The Getting Is Good.

We need a discussion of common models of contracting.  How is an 
ROA declared and maintained by an organization to organization 
process.   The models we used at a decade ago used the 
process/control design familiar to systems analysts.  There 
were interesting parallels with real time systems but those 
may not be as important as I once thought they were.  

len


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)