RE: Client-side-resolved Indirection

[Paul Prescod]
>[Ken Holman]
>>Certainly the SGML Open scheme has its benefits and features, but I
>>agreed with Debbie that the minimum is a simple string comparison.  If I
>>choose to go beyond that with an SGML Open catalog, I can choose to do
>>so without impacting on my marked up source.
>
>Could you clarify here? Do you and Debbie wans a simple established
>mechanism for name resolution, or just the option to put in the public
>identifier (which is what I have been pushing for).

[Michael Sperberg-McQueen]
>But one thing seems clear to me:  if we have them, we
>need to specify how to handle them.  If we don't, we are giving up
>without reason on the goal of interoperability and complete explicit
>definition of the language.

I did not think that an established mechanism for name resolution was
required, but I now think an XML catalog is necessary to communicate to
a recipient the mapping of PUBLIC identifiers in a set of entities (if
there is only one entity, there are no PUBLIC or SYSTEM identifiers).

BTW, I think PUBLIC identifiers are far more "interoperable" than SYSTEM
identifiers.  If I build an (URL-only) XML Application for my
colleagues, then I may have to hardwire the working URLs that are behind
my firewall.  When I choose to ship that application outside the
firewall, I am obliged to modify the raw (working) sources to change the
SYSTEM identifiers to URLs outside my firewall and then make the URLs
publicly available so that the SGML files supplied can be used by the
recipient without modification.  If I can't make the files publicly
available on my server (or the recipient doesn't have HTTP access) the
recipient must determine from (perhaps cryptic) URLs which entities map
to which SYSTEM identifiers.

If, however, I shipped the package of SGML sources with only PUBLIC
identifiers, then the recipient can choose where in their own
environment to place those files, and only change a catalog file.

Catalogs are not meant to be system independent (though, as I mentioned
before, there are relative path conventions in the SGML Open catalog
that may mean I don't have to change your catalog to use it on my
system), they are meant to be system specific.

Personally, I would suggest a subset of the SGML Open catalog format. 
We released one of our products before there was an SGML Open and much
of our own implemented catalog format turned out to be compatible with
what came from SGML Open.  The base of what is needed is the keyword
PUBLIC, followed by a public identifier, followed by the information
required to identify the entity (if a system identifier with a relative
path, the path is relative to the catalog file).  By requiring both
identifiers to be quoted, future versions of the XML catalog can
implement other keywords.  I also like having comments in catalogs, but
that can wait (I've included it below for completeness).

Since the use of PUBLIC is not obligatory in XML, the use of a catalog
is not obligatory.

Here's a thought ... could an XML catalog could be either a "system
file" or "system documentation" based on how the author wishes to create
it?  For example, the following could be a catalog in the first file in
a MIME envelope of three files:

  PUBLIC "+//ISBN 1-55160::MSL//DTD Presentation Slide Show//EN" "Second
file in MIME envelope"
  PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN" "Third file in MIME
envelope"

(this is probably a poor example as I think I recall that the MIME parts
can be uniquely identified, which would be the most appropriate SYSTEM
values, but I hope that my point is getting across)

>>Then again, need XML establish the "environment" in which XML PUBLIC
>>identifers are dereferenced?  Is it in the scope of XML to go outside
>>the syntax of the markup to specify any obligatory mechanism by which
>>information in the markup is handled?
>
>Well, URLs must be handled according to URL semantics so we *could*
>specify
>a resolution semantic for public identifers. But I think that would put
>an
>extra burden on implementors, risk XML's acceptance, and
>inappropriately
>disqualify the URN effort before it got off of the ground.

Then perhaps the above use of a catalog as "system documentation" takes
the "burden" off of implementors: if I choose an XML system implemented
without the XML catalog, then the catalog file is documentation to me,
the consumer; if I choose an XML system implemented with the XML
catalog, then the catalog file is a system support file to my software.

In another message I'll prepare a straw-man specification of changes to
XML for PUBLIC identifiers.

Responses to this thread can continue on the merits and drawbacks of the
concept.

......... Ken


--
G. Ken Holman            Tel:  +1 613 596-CADE(2233)    /\ /\
Chief Technology Officer Fax:  +1 613 596-5934          \/ \/   Computer
Microstar Software Ltd.  WATS:  1 800 267-9975        /\     /\ Aided
3775 Richmond Road       Mail: gkholman@microstar.com \/     \/ Document
Nepean Ontario           Info: cade@microstar.com       /\ /\  
Engineering
CANADA K2H-5B7           Web:  http://www.microstar.com \/ \/
--
1605 Mardick Court, Box 266    Phone:  +1 613 489-2987
Kars, Ontario CANADA K0A-2E0   E-mail: gkholman@CanadaMail.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

mQCNAjHOimAAAAEEAK47HbDtZZB8hJBk+r9Zh7m7QxdFHTaz/m200QQ7J9XX4QYs
h6hsuP6ZqBJXyLdmIVMEwR6Ry6oxjKMd6BRJ8OGScD89eIghgbrpMX+900NxM0x2
v3yWO9ki2gKRPrn4vlCXznnmcmsyke0G02T2LefXbgZHyVSqDSOLy8nwuN7dAAUR
tClHLiBLZW4gSG9sbWFuIDxhYjk0NUBmcmVlbmV0LmNhcmxldG9uLmNhPg==
=IN3T
-----END PGP PUBLIC KEY BLOCK-----

Received on Monday, 2 December 1996 16:58:10 UTC