Re: B.9 Formal system, public identifiers?
From: James Clark <email@example.com>
Subject: Re: B.9 Formal system, public identifiers?
>> >I'd still like to keep at least a subset
>> >of the nice clean FSI syntax.
>> What is the functionality you want from FSIs that you can't get from URLs?
>At least better opportunities for indirection.
How do FSIs offer this? What makes you think URLs can't offer indirection?
URLs can provide indirection (or at least a server can) but they
bind the resolution protocol at the time the name is assigned. Using
URLs as the only syntax for system identifiers doesn't allow other
forms of name to be used later on. If we specify FSI syntax, and
then restrict the FSIs to be URLs, there is a nice path to more-robust
identifiers at no more cost than we incur by implementing URLs to
Similarly, if we allow FPIs and restrict our catalogs to mapping
FPI -> FSI, the implementation will be a lot simpler than current SGML
implementations. We need not even use the SGML/Open catalog syntax if
it makes parsing to hard.
Having the FSI syntax to allow extension seems easy and
foresighted to me. FPI's may add complexity (in that they need to be
resolved, but if we have external entities at all, FPIs should be
available -- We need the slot in the syntax if we ever want to have
the FPI/FSI distinction -- and it is a critical distinction. So I
guess I think we need to FPIs into the syntax even if we consciously
decide not to specify how they should be resolved. (Assuming that we
have external entities at all. On that question I can't make up my
If we are to eliminate the distinction between FPI and FSI (or
URN/URL or pointer/name, choose your terminology), then we would have
to eliminate URLs and other pointers I think, and standardize on FPIs
only. However, this would fly in the face of familiarity, and be hard to
implement, so we should probably avoid the high road on this issue.
But making it impossible to ever do the right thing and use
location independent naming seems a high price to bear.
RE delenda est.