Re: 2.1 a-d: Link Recognition by Reserved Attribute?

Murray Altheim wrote:
> 
> >It's logical, but my experience is the great unwashed masses don't
> >design DTDs or use arch forms.  That argument is overrated.  If
> >I have to live with one and only one way of doing it, I prefer
> >to have the GI left to my discretion, and the superclass assignment
> >in the attribute as a silent but helpful partner.  After all
> >this talk of extensibility and something more powerful than
> >HTML, I hate to see us return to precisely the same design by
> >giving them a non-extensible set of link types.
> 
> I don't assume that people will hand-code a DTD, but I could see a
> Microsoft Word-like application that builds its document storage model on a
> base DTD and stylesheet that the user unknowingly modifies as the document
> outline and styles are filled in. Tens of thousands of DTDs every day.

The utility of a DTD is in its ability to provide a validatible 
agreement.  Style should not be filled in to the DTD.  Otherwise, 
use HTML and be done with it.

If they want Word, use Word.  If they want markup according to a
prearranged set of element type definitions, use XML or SGML.
Right now, Word does have a base DTD.  It is the set of properties 
that make up RTF, the Para as divider, et al. 

For XML to be useful, it should act as a recognizable signal in a
communications process.  That is, send the Request for Information, 
get Information.  Send Request for Quote, get Quote or RFI.  It
is the ability to pair schema like this that gives XML a utility.

As a way of configuring Intranet/Internet enterprise communications 
where that enterprise is itself classified by either the product 
or service it provides, XML has utility.  As merely a way to 
export flat files between word processors,  RTF is more 
compact and more efficient. 

> XML applications may also be developed to fill niche roles in various
> industries, with the idea that interoperability is gained by using a
> commonly-available XML browser. 

A niche is as wide as its requirement.

Interoperability?  For that, Word is just as and probably more
effective.  Buy from 
Gates and solve the world's interoperability problems.  COM/OLE 
is very good for that.   It is only when one wants to be independent 
of the "commonly-available" browser that markup has utility. 
Repurposing 
of information, rehosting of information, archival of information, these 
are the utilities of generalized markup.  Satisfying the architecture 
of "a common browser" is how HTML works.  If we can't do better than 
that, then XML is a failure and we'd best return to SGML before the 
XML effort confuses the market to the point of washing their 
hands of all of us.

> CML might just be the first of many
> industries that would want to take advantage of a simplified, custom
> markup. Not thousands of DTDs, maybe a stable dozen. But browser vendors
> (and I'm guessing average users) would much better understand a common GI,
> with an option to use an attribute left to others.

A community of interest can define a DTD, agree to it, publish it, and 
use it to establish configured communications.  If all we build here 
is a common set of tags, this is Docbook or 28001.  We already have
those.
We know how to do that now, have done it, and in some cases, had 
good success.  XML as a common tag set is just the CALS registry.
 
> As I mentioned, I'm much more an advocate of using attributes, but a
> stable, understood GI might be a choice *some* people would prefer.
> Netscape, forinstance.

Screw Netscape.  They don't want this.  We want this.  That is 
why we are doing this day in and out.  When Netscape sees a 
market advantage, they will buy in.  If they don't, bully for us.
 
> >They don't get the power without the responsibility to learn
> >the technique.
> 
> Whoa. You obviously don't work in marketing.

No, I have an honest job. ;-)

My boss says that marketing is everyone's job.  It is.
But selling water by the river takes a mighty persuasive 
salesman.  We have to sell XML to an a customer who 
already has HTML, knows about SGML, and in some cases prefers 
SGML.  It is the latter cases we can sell to most effectively.
I've already received one review from a customer considering 
that transition.

XML:  for those who need SGML but can't afford to wait.

len

Received on Friday, 14 February 1997 12:20:40 UTC