Re: The furore over PUBLIC

Peter Flynn wrote:
> 
> At 15:30 29/03/97 -0800, Jon Bosak wrote:

> >I confess that I am extremely uncomfortable with the position in which
> >we currently find ourselves.

That's good.  That means you are in new teritory.  It's exciting.

> I share the blame for having been a pubid zealot for so long. I'm now
> part-converted to using URLs -- for the moment, as a stopgap -- but I
> really do want to avoid having to reopen this can of worms in 1998.

The URL is the fundamental location type (not precise, but not circular) 
for the WWW.  It is not assumed; it is the contract.  Just like IUnknown 
makes COM work, URLs make the web work.  To even argue that is a 
waste of our effort.  It is the contract.
 
> Is it too much to propose that an identifier must be
> 
> either          SYSTEM  "url"
> or              PUBLIC "fpi" "url"
> 
> and leave it to the much-vaunted "market forces" to resolve the issue?
> 
> After all, we're constantly being told not to write specs, that American
> Business knows far more about software specification than any team of
> gureaux, and that the market defines the standard anyway :-)

We are writing specs.  That is what we do.  How they fare depends 
as much on their reasonableness as their currency.  No argument.
They also depend, probably much more than they should, on perceptions.

But we can play that game a long time and not succeed in producing 
a viable technical specification.  Don't Fear The Reaper.  Do the job.
If this XML is to really be SGML On The Web, then make that work first.
Let the marketing be something we all do because we do it anyway.
Debate your requirements; not your ambitions.

Some straight talk.  Very soon, I will be leaving this part of 
my profession and taking on a different set of responsibilities.
But there is one role left to play, and I need your help to complete it.

I've been tasked to propose the object addressing portion of the 
IETM proposals for the IETM WG of NAVAIR.  I want that proposal 
to be XML compatible if not in fact, precisely the XML solution.

Why?  

For a decade now, we have fought for and used SGML in DoD.  
At times, that has been hard, but after a decade, what 
I can say with certainty is that it works.  Of all the CALS specs, 
standards, initiatives, experiments and boondoggles, SGML works.

Now they want to use the Web technology.  Many are willing to 
lose SGML and XML in this process.  Some are very anxious to do so.
The JCALS browser of choice is Netscape.  This decision, I 
am told, was heavily influenced by DISA despite the fact that 
DoD holds one of the largest SGML legacies and Netscape is the 
one company that has publically declared their distaste.  That makes for
a 
very strong "market force".   It does not augur well for XML.
Again, too much depends on *the game*, and unfortunately, 
in the IETM business, that is as much a tragedy as a bad joke.

What has been asked for is a simple and commercially viable way 
for DoD to organize the technical documentation such that an 
author need not embed addresses within the document instance.
It is felt that this will enable a more manageable document 
solution, and provide what the web does not:  links that don't snap.
Tney don't necessarily run on the WWW or the Internet, but 
they should use the same technology.  Even DoD recognizes a tsunami.

o  Will a formal and well-maintained registry based on catalogs 
provide this?

o  What else is needed?  For example, is there any good reason 
to adopt a new protocol (eg., non-HTTP)?

o  Could the XML solution (whatever you decide) work for non-XML 
notation types (eg, PDF)?

o  Will it work within the object interface proposals of COM 
and CORBA?

Not to rush you; I can't do that.  But the gate closes 
by year's end, and I will out much sooner than that.
How well XML supports link management is a critical issue.

Len Bullard
Lockheed Martin

Received on Saturday, 29 March 1997 20:34:24 UTC