Re: OT: Proposal for Describing Web Services that Refer to Other Web Services: R085

Thus quoth Champion, Mike (~ 25-Apr-03 1:21 PM ~)...
> 
> 
>>-----Original Message-----
>>From: Mark Baker [mailto:distobj@acm.org]
>>Sent: Friday, April 25, 2003 11:53 AM
>>To: www-ws-desc@w3.org
>>Subject: Re: Proposal for Describing Web Services that Refer to Other
>>Web Services: R085
>>
> 
> 
> [Off topic, but hey it's Friday!]
> 
> 
>>Consider the telephone system.  I only need an identifier 
>>(phone number) and a client (phone), and I can call someone.  
> 
> 
> Oh really? You need to know not only the phone number, but the rules for
> parsing the number into its component parts (e.g. country code, area code,
> local number).  Then you have to figure out the steps needed in your current
> location for a) getting an outside line b) whether or not an area code is
> needed (this may be a North Americanism); c) figuring out whether the call
> is international or not, and if it is you need to know the local convention
> for initiating an international call as well as the country code that you
> may have parsed out of the phone number. 
At the risk of obfuscating things more, I'm not completely sure how
things are really all that different.

Methinks one has equivalent things one might need to know for URL's as
well.  One needs to know a) what's my proxy server (outside line), b)
need the whole domain or just an abbreviation (do I need an area code),
c how much of the domain/url do I need [xxx vs. xxx.some_division vs.
xxx.some_division.some_company.com] (international or not?).

While most of us figure this out once, configure our browser
appropriately, then go on (so browser's are more configurable than
phones), one might still have to know it.

At work, when I was at a /big company/, folks "near" me could get to my
web servers as "http://fredsmachine/".  If they were in Europe, they
might need "http://fredsmachine.us/" or "http://fredsmachine.hq/".  If
they were outside the company (and if it had been made public), they
would have to use "http://fredsmachine.us.bigcompany.com/".  Moreover,
if I were traveling, I needed to have such a context to make things work
-- just as I do to call my home/cell phone.

One can certainly argue that "bigcompany.com" could have done a better
job, but, indeed, such shorthands and configurations are not uncommon.


> 
> Let's look at a concrete example.  Software AG's main number on our homepage
> is listed as  +49 6151 92-0  To actually call the receptionist there from a
> random spot in the world, you need more information than just the phone
> number. From my cellphone, I can actually enter +49 6151 92 0 . From my
> home, I would dial 0114961510.  From most businesses in the US, one would
> dial 9011496151920  From most places in Germany (as best I understand the
> system!) one would dial 06151920.  From within the building, you would just
> dial 0.  From a random hotel in Paris, or Hong Kong, I have NO IDEA!
> There's usually a little booklet next to the phone that explains the local
> conventions.
> 
> Worse, one often needs to know the "after the answer" protocol for dialing
> an specified extension, conference access code, or whatever.  As a practical
> matter, many of us also need to know the local access numbers for our
> calling card providers and the local convention for using it (for example, I
> can attest that the order in which you dial the account code and the desired
> number is different for MCI in the US and in Germany).  And if you  using a
> modem, you have the additional problem that physical dial tone signals are
> different in different countries, and you may have to pause dialing at
> various points to make sure that the phone network is ready for the next
> digit. I've spent long hours in hotels trying to figure out how to call an
> ISP to get email; I guarantee you I did not "only need an identifier"! 
> 
> Web services seem simple by comparison :-)
>  
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301

Received on Monday, 28 April 2003 18:56:19 UTC