W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > December 1996

Re: re ERB discussion of public identifiers

From: Terry Allen <tallen@fsc.fujitsu.com>
Date: Sat, 14 Dec 1996 17:15:26 -0800 (PST)
Message-Id: <199612150115.RAA24389@ishtar.fsc.fujitsu.com>
To: pflynn@curia.ucc.ie, w3c-sgml-wg@w3.org
Peter Flynn writes:
| Terry Allen writes:
|    | 3. Put a slot in the syntax for PUBLIC identifiers...
|    |    3* ...and require an accompanying SYSTEM identifier
|    Why require?  
| Because to go by current performance, processors and apps on the Web
| neither know nor care about PUBLIC indentifiers (with one or two
| obvious exclusions), and certainly wouldn't know where to go to broker
| a request for resolution.

If they cannot handle PUBLIC right now, then SYSTEM should be used
by authors.  But that is different from requiring conformant docs
to include SYSTEM.  What happens when people start to find URN
resolution services to be useful and reliable?  Do they then
have to include a bogus SYSTEM value just to conform?  (Today
I found this PUBLIC placeholder:  -//asdfasdf//asfdsf//EN.)

|    Just say that the author has the two choices of
|    how to refer, by URL (SYSTEM) or URN (PUBLIC), or both. 
| This is exactly the problem I pointed out the other day. It is
| insufficient to allow both without indicating the sequence in which
| they should be tried, regardless of how any resolution is to be performed.

And I meant to reply to your point, but forgot.  

 - why is order significant to correct resolution?
 - why does the XML spec need to specify the order rather than
    the user's configuration file?
 - why shouldn't the user have the option of trying both, and
    doing something further if the two results don't match?

    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html
Received on Saturday, 14 December 1996 20:16:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:20 UTC