Re: identify XHTML DTD by URI, not by FPI

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

> > 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
> 
> [...]It concerns the syntax of a name by which a document or part
> of a document (an anchor) is referenced [...]"

Yup.  Argument by assertion.  "Syntax of a name by which [something]
is referenced".  *A* name?  Classic example of persuasive definition,
sometimes known as begging the question;)

> > The issue is whether names are of value to the Web Community.  
> > (Btw, whether they are to the W3C is a different issue.)

Stet.

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

That's the point.  There are no comprehensive/decisive criteria.  If
there were, the Undead Debate would have been over long ago.

  http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jun/0223.html

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

Again, if morphology were all there was to it, the debate would have
been over a long time ago.

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

Actually #NT-ExternalID, but yes, you're right.  Sorry.

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

May?  Isn't "should" the point of the W3C's interests here? 

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

Because (a) in my experience, double duty comes back to bite in the
longer haul, amd (b) it's an implementation issue, not a specification
issue.

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

Then why not leave it to implementors to decide what is fundamental
for them?

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

I've made no such assertion.  In fact, I tried to make it clear that
the W3C's interests were a different issue.  You didn't ask, and I
didn't answer, "how could it benefit the W3C?".  You wrote: 

> > > How is it valuable to the web community for W3C to issue Formal
---------------_^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > Public Identifiers in addition to URIs [...]

I understand how the W3C would like nothing better than to be the
exclusive spokesman for the Web Community, but until the W3C arranges
to excise PUBLIC identifiers from the next edition of the XML spec, a
regard for the possibility of "more things than are dreamt of in your
philosophy" might just be the better part of wisdom.


Arjun

Received on Wednesday, 16 February 2000 00:10:55 UTC