OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: XML Schemas: Best Practices

[ Lists Home | Date Index | Thread Index ]
  • From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
  • To: "Thomas B. Passin" <tpassin@home.com>, xml-dev@lists.xml.org
  • Date: Fri, 01 Dec 2000 12:24:02 -0600

Right.  On the other hand, the purpose of a 
registry is to make an association and that 
is also what a catalog does.  I guess it 
depends on how sure one wants to be that 
the Thing Pointed At is the The Thing, 
and where the decision is made.
The SSN is good:

1.  As long as you are in the US. Venue 
authority makes a difference.  SSNs are worthless 
outside the system that is the US.

2.  As long as it is legal for you to 
use the SSN.  The rules declared by the 
venue authority make a difference.  SSNs 
can only be used if the system says you 
can use them.

The point is that there is not a universal 
semantic or even if there is, you don't 
need that to solve the engineering 
problems for communication in noisy and 
noiseless channels.   Shannon makes it clear that 
you don't want to go down that rathole.  
You want to talk in terms of *systems* 
that have means to get candididates and rules to choose 
among sets of equal possibilities.  If 
you can do that, noise isn't a problem. 
You do want to know whether the system 
is closed or not (can it modify an 
environment and therefore produce a 
sideeffect introducing uncertainty - 
who is shaking the chads?, aka, the 
superstition problem when a filter 
introduces a belief system). 

A 404 is one answer as long as you can 
live with that. For some missions, you 
can't.  Quality of service is negotiated 
as part of procuring a service and comes 
with terms and conditions.  Known services 
can play tit-for-tat (renegotiate on 
default of service).

TimBLs wet dream is that computers can 
do all of this automatically.  Heck, 
we can't even be sure we got an honest 
ballot count here and we have a lot 
of computers.  Problem is, we also have 
a lot of lawyers shaking chads.  Systems 
that resolve critical decisions must have 
the granularity of signal to make the 
decision regardless of the noise and 
that is a "speed is money, how fast can 
you afford" dilemma.  The criticality of 
the decision has to be known to establish 
the Ts&Cs among which will be traceability 
to enable you to establish culpability.  
The reliability of the signal (dimples) 
is what you build in the filters for.


Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@home.com]
Sent: Friday, December 01, 2000 11:44 AM
To: xml-dev@lists.xml.org
Subject: Re: XML Schemas: Best Practices

Len Bullard said -

> Chase that thought you are
> having a bit further in light of namespaces being
> a signature for an interface.  Then ask yourself if
> you need or want that given that regardless of the
> spec, the use of the URN/URL means to too many, a
> location, not an authoritative owner of a domain.
That's why I advocate that actual namespaces ought to be URIs that are
clearly not URLs.  That would discourage people from trying to treat
them as if they were.  Especially in examples.   So what if there's no
registry guaranteeing uniqueness and permanence?  There isn't for urls
either, but that's not stopping anyone.

To me, namespaces are something like US Social Security numbers.  If I
say that John Smith owns such-and-such a house, well, there are many
John Smiths.  If I say that when I say "John Smith", I mean the person
with a ss number of 123-45-6789, that makes it unique.  I don't expect
or need other information to be coded into the ss number.


Tom P


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS