Re: identify XHTML DTD by URI, not by FPI

On Tue, 15 Feb 2000, Dan Connolly wrote:
> Arjun Ray wrote:
> > On Thu, 10 Feb 2000, Dan Connolly wrote:


> > > (nor the interests of the Web Community)
> > 
> > This isn't clear at all.

> Would you please elaborate? 

  1. The W3C is a consortium.  

  2. The Web Community comprises a far wider range of people,
     organizations, and interests.

  3. A significant portion of W3C deliberations are closed to
     the Web Community.

  4. The interests of the W3C and the Web Community need not
     coincide, and given #3, perhaps cannot.  

IOW, the conflation, no matter how convenient, is always inherently
debatable. 

> How is it valuable to the web community for W3C to issue Formal
> Public Identifiers in addition to URIs that are guaranteed to be
> highly available and not reassigned to other purposes?

FPIs are names, and URIs are not.  The issue is whether names are of
value to the Web Community.  (Btw, whether they are to the W3C is a
different issue.)  The asserted availability and/or immutability of
a URI is material and useful but neither comprehensive nor decisive.

> > To reflect the reality of a mapping being convenient for operational
> > purposes.  That's the fundamental distinction between PUBLIC and
> > SYSTEM.   $system_id = $catalog{$public_id}
> 
> In what way is this distinction fundamental?

In the same way that the distinction between the key and the value of
a hash table entry is fundamental.
 
> I can see where it's useful to be able to relate standard
> identifiers to local identifiers by operational convention,

That's precisely the point.  The meaning of the SYSTEM keyword is
"local".  There's a lengthy discussion of this in the SGML Handbook,
accompanying Clause 10.1.6 "External Identifier".  It's also the
reason why, inter alia, the SYSTEM keyword need not be accompanied by
a system literal at all; FSIs (Formal Sytem Identifier) were, perhaps
had to be, invented later; and the WebSGML TC has added the '+//IDN'
registered owner class to FPI syntax.

> and even so, it doesn't seem fundamental: even the $local_uri is
> mapped to filesystem, an inode, a block within the inode, and so
> on.
> 
> c.f. The Name Myth -- Axioms of Web architecture
> http://www.w3.org/DesignIssues/NameMyth

<rant> 
This inode stuff is really silly.  Why stop the regress with a casual
so on or etc.?  Why not carry it down to disk sectors or surface
coatings or even quarks in the freaking electrons?  If the point of
such a casuistic exercise is to strip the word "fundamental" of any
meaning, then a little better than amateur philosophizing might just
be in order.

And, FWIW, the "only true location" is in four-dimensional space.  
Gawd, anything for a trip into the ozone. 
</rant>

We don't need metaphysical ruminations to distinguish names and
addresses.  Ordinarily, neither establishes identity.  Nor need we
worry over which is more common, names having nore than one address,
or addresses having more than one name.  When it comes down to the
W3C's assurance that it's just fine in this case to use an address as
a name, that's not quite the point either.  The point is that where a
name is *needed*, an address - no matter how it could walk, talk and
associate with none but - isn't good enough.  The watchword is
"prudence".

The name vs address argument is an endless one.  There's years worth
of mail archive stuff on URNs, for instance.  FSIs bit the dust in the
early XML discussion, too.  However, there were reasons - if not
anything else but to give the benefit of doubt - for retaining PUBLIC
identifiers *at all* in XML, and on those grounds alone I see no
reason why the W3C should foreclose options from the Web Community.


Arjun

Received on Tuesday, 15 February 2000 22:34:50 UTC