xml-dev - RE: URI concerns continue

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

No contest.  If the superstition becomes reliable practice, 
it is no longer a superstition.  It seems to me that 
proposals changed along the way.  I had the namespace 
discussion with David Megginson when they were proposed 
and I was assured and others were assured repeatedly 
that the use of the URwhich string was specifically  
and only to have a disambiguating prefix.  At that 
time, I stated that the users would trust their own 
experience that any string beginning with http:// would 
be marshalled, made blue, underlined, and become 
clickable just as the one I just typed did.  It 
won't resolve (incomplete), but it will click.  Given 
that, they would have a hard time with any other 
expectations.  So far, that is about right.

Remember folks, most users can't and don't read 
RFCs to discover implementation minutiae.  They simply 
trust the system they use every day and blame the 
vendor if things aren't as expected.  We are the 
loosely coupled control between them and frustration.

The thread on FPIs is not meant to change the design 
but to point out that the use of these in a DOCTYPE 
along with the system identifier is clear and the 
expected behavior is clear.  That there is not a 
100% guarantee for any resolution service is beside 
the point because the contract can state the 
probability and we do that every day in other 
contracts for things such as system performance, 
eg, time to return on a specific transaction.  At the 
very least, I can name something without fear of it 
being made blue, underlined, and become clickable. 

So it appears at this time that the user of the 
FPI and system identifier has a clearer contract 
and the FPI comes closer to describing a workable 
namespace.  The problem is that guaranteeing 
persistence and global uniqueness has to be made 
in systemic terms and FPIs have no system to guarantee 
that whereas URIs do (DNS).
 
I am having a hard time working out what the user 
of the URI namespace can expect.  So far, they are 
clearly able to disambiguate names in aggregate 
instances. 

Yes it is complicated.  One has to wonder about 
all the hype on B2B, B2C, etc. in a system that 
doesn't seem to provide clear contracts for 
behaviors.  This thread is at least educating 
me as to the thinking if not the clarity of 
agreement.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram

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


From: Simon St.Laurent [mailto:simonstl@simonstl.com]

The 'superstition' is much more broadly understood (and used) than the
purported fact.  

Common URL usage has bred a widely shared set of assumptions in communities
which frequently lack any interest in URI philosophy.

I'm not convinced that the understanding of strings beginning with things
like http, ftp, mailto, file, and other commonly encountered strings known
to identify retrieval protocols in URLs is 'wrong', whatever RFC2396 may
claim.

It certainly complicates matters, however.