Re: ERB discussion of public identifiers

> 1. Leave it as it is

Please, no....

> 2. Agree that we'll put PUBLIC identifiers into XML *when* we are ready
>    to specify the resolution mechanism; the practical effect is almost
>    certainly that they don't go in for now.

Maybe.  Doing it this way would keep XML system from fragmenting and
returning to the current state of "I do it better--do it my way!" marketing.

> 
> 3. Put a slot in the syntax for PUBLIC identifiers...
>    3* ...and require an accompanying SYSTEM identifier

No.  This would break existing documents.  It is also philosophically wrong.
If I give a public identifier, I really don't want to embed system identifiers.  
... not to say that it wouldn't work in some cases.

Now, I could write perl script that filters.... slap!  sorry, I been writing
too much perl/SGML filters lately.

>    3a - say nothing about resolution mechanisms, perhaps providing a
>         taxonomy of available technologies in this area

Yes!  Resolution technologies do not belong in a document spec.

>    3b - document one resolution mechanism, but not make it required.  
>         This is somewhat similar to our i18n approach, where we bless 2 
>         encodings but admit the possibility that people use others.

No.

>    3c - document one resolution mechanism as before, but make its use
>         mandatory for XML processors.

No.

I would seem to me that we need *two* standards.  One that specifies how
the document is encoded and one that specifies the 
technical-environment-of-the-day-that-makes-it-go standard.  Why couldn't we
have XML standard and the XML-web environment standard for resolutions and
other such things.

One of the powers of SGML in a good number of the systems that I have built is
the ability to replace the technology underneath and *not* change the documents.
It would seem that in XML we want this as well. 

If we have a core XML document encoding standard and ancillary standards
that define the environment for transport, resolution, etc. we can change
the environment later and still use the document encoding standard.  In 
addition, it can well define the difference between representation of
information, understanding that representation, and environmental processing
of such information.  Such well defined components will keep people from
developing systems in which encoding understanding is mixed with environment
processing--as the current implementation of the web has done in some
cases.

It is my proposal that we have the following *separate* but related standards:

* XML encoding as a subset of SGML
  - defines the encoding much as XML 1.0 does today.

* XML-Web environment
  - defines resolution mechanisms, transport, etc.

...later on down the road we might want:

* XML-CDROM environment
* XML-MAIL environment

... etc.

XML encoded documents *will* outlast the technology we use to transport and
process it today.

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608

Received on Saturday, 14 December 1996 12:42:20 UTC