Re: URL better than FPI

Arjun Ray wrote

> No.  They're exactly the same.  The real problem is that, under the
> current rules, a URI can't be the minimum data following the PUBLIC
> keyword.  line--

Under whose rules? I can see _nothing_ in the XML spec that puts any
constraints on the public identifier except that it consists of PubidChar.
So as long as the URI is encoded in (say) utf8 and then %HH encode any
disallowed characters, it would appear that that would be usable as
the public identifier (although it would break any sgml based system
expecting an FPI)


> That is, there should never be a need for a PUBLIC *and* a SYSTEM
> identifier.

I agree, in an ideal world this would be true. But in XML as currently
defined main point is that you _do_ need two: a canonical name and a
system address (it matters not too much whether the canonical name is
based on FPI or URI conventions)

XML does not mandate support for any particular catalog syntax or
support for http. Thus if as Dan Connolly suggested XHTML mandated
that all conforming XHML documents start 
SYSTEM "http://www.w3.org/....."
or
PUBLIC "xxx"  "http://www.w3.org/....."

Then the end result would be that many (perhaps the majority) of
validating XML parsers would not be able to even parse a conforming
XHTML document.

In a section on conformance you should restrict yourself to features
that you know are available in a conforming XML system. Unfortunately
that means for XML the _only_ thing you have available is to suggest
editing the document so that the system identifier points to a copy of
the dtd usable on your system. That means, if you want to also have
a canonical name in the doctype declaration, XHTML has to use the
only other available slot, which is the public identifier.

This is the main reason why I think XHTML has to use the public
identifier, it is nothing to do with the merits of FPI versus
URI, it is just to do with the lack of a mandated standard
resolution mechanism for external identifiers.


David

Received on Monday, 21 February 2000 04:57:46 UTC