Re: The furore over PUBLIC

At Mon, 31 Mar 1997 21:01:06 +0700, James Clark writes:
> At 00:47 30/03/97 +0000, Peter Flynn wrote:
> 
> >Is it too much to propose that an identifier must be 
> >
> >either          SYSTEM  "url"
> >or              PUBLIC "fpi" "url"
> 
> This seems a reasonable compromise to me.  No interoperability is lost,
> because there's always a URL that the system can use.  It adds very little
> burden to implementers: they can just completely ignore the public
> identifier if they want.
> 
> The spec could just say something like:
> 
> In addition to a system literal an external identifier may include a public
> identifier.  A system may use the public identifier to try to generate an
> alternative URL.  If a system is unable to do so, it must use the URL
> specified in the system literal.
> 
> In a future version, when we have a resolution mechanism, we could maybe
> allow omission of the system identifier when there's a public identifier.
> 
> The question is: do those who have been clamouring for public ids think this
> is better than no public ids at all?

Certainly. Beggars can't be choosers. I feel it unfortunate we've been 
reduced to that. I have read over almost every message pertaining to
this subject, and I find very little new information. The proposal is
basically sound, and we're back to the same basic issues. Much of the
rest sounds like red herring.

I fail to understand why a default mechanism is *required*, that the ERB
"can't move forward" until a default mechanism is determined. I find this
untenable; that if we are designing an open-ended "meta-language", the 
scope of applications is so wide that to pretend to understand either
implementors' or users' needs at this point is mere speculation. Sure,
there are several scenarios that come to mind, but _how_an_XML_processor
_obtains_a_resource_ seems entirely beyond the scope of a language design.

We are essentially trying to encompass both the HTML and HTTP specs in
one shot, which seems unnecessary. Several vendors' reps have made their
points quite clear, and as much as I hate to say it, let the market speak.
The variety of needs that XML may serve will require the entire variety
of resource references and resolution priorities:

  1. SYSTEM only
  2. SYSTEM and PUBLIC, priority on SYSTEM
  3. SYSTEM and PUBLIC, priority on PUBLIC
  4. PUBLIC only
  5. determined entirely at processing time

I can't speak for all of Sun, but we currently do and will continue to 
use PUBLIC ids for our documents. If XML doesn't support PUBLIC, use of
PUBLIC ids will require either that we don't use XML for specific
applications that would require it, or we come up with some hack. I 
much prefer the former, but would rather simply have PUBLIC be an
equal option, with priority determined by my needs rather than the XML
specification. The scope of possible applications demands it.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey                    <altheim@eng.sun.com>
Tools Development & Support
Sun Microsystems, 2550 Garcia Ave., MS UMPK17-102, Menlo Park, CA 94043 USA
         "Give a monkey the tools and he'll build a typewriter."

Received on Monday, 31 March 1997 13:43:36 UTC