Re: identify XHTML DTD by URI, not by FPI

Arjun Ray wrote:
> 
> On Tue, 15 Feb 2000, Dan Connolly wrote:
> > Arjun Ray wrote:
> > > On Thu, 10 Feb 2000, Dan Connolly wrote:
[...]
> > 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.

Hmm... argument by assertion. Two can play at that game:
yes, URIs _are_ names; they were conceived that way in 1991:

"Document Naming

This is probably the most crucial aspect of design and standardization
in an
open hypertext system. It concerns the syntax of a name by which a
document or
part of a document (an anchor) is referenced from anywhere else in the
world.

As many protocols are currently used for information retrieval, the
address must
be capable of encompassing many protocols, access methods or, indeed,
naming schemes.

The WWW scheme uses a prefix to give the addressing sub-scheme, and then
a
syntax dependent on the prefix used, in order to be open to any new
naming
systems. "
	-- Naming -- /DesignIssues
	http://www.w3.org/DesignIssues/Naming.html


>  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.

So what are the comprehensive/decisive criteria that the string
	-//W3C//DTD XHTML Basic 1.0//EN
meets that the string
	http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd
does not?

> > > 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.

That's not a fundamental distinction. The value 42 may be used
either as the key or the value in a hash table. Same with URIs.

> > 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".

Not in the case where the SYSTEM is the web, i.e. the case of XML.
In that case, the convention for SYSTEM identifiers is global...
the global convention is the URI specification.

>  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;

In XML (the domain of this discussion), the system literal is
a required part of the syntax.
c.f. http://www.w3.org/TR/1998/REC-xml-19980210#NT-doctypedecl

> 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?

That's exactly the point I'm making: what is viewed from one level
as an address may be viewed at another level as a name; what is
used as the key in one hash table may be used as a value in others.
Why create an artificial partition between the set of names
and the set of addresses? Why not use one big pile of identifiers,
and put them in the role of name when that's handy, and put them
in the role of address when that's handy?

>  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.

To say that the same string can be used in some cases as a name
and in some cases as an address is not to deny that the word
"fundamental" has any meaning.

> 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.

Again, argument by assertion. So I counter: yes, it is good enough.

>  The watchword is
> "prudence".
> 
> The name vs address argument is an endless one.

It is a long-standing one, yes. But let's hope there is an end to it.

>  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.

I do not propose to foreclose any options. Members of the Web Community
are free to use FPIs if they find them to be valuable. But you have
not made any argument (other than by assertion) as to what value
W3C would derive from the use of an FPI to identify the XHTML Basic DTD.

-- 
Dan Connolly
http://www.w3.org/People/Connolly/

Received on Tuesday, 15 February 2000 23:10:14 UTC