Re: XML catalog draft

I'd said:
> | I think that it would be better to specify that URNs be used (which I
> | would support) than FPIs (which I do not support), as there is still
> | no resolution mechanism that will scale up to millions of FPIs even
> | proposed, let alone working, as far as I can see.

Jon replied:
> With all due respect for the URN effort, I'm not convinced that it's
> very far along toward implementation, either.  And I'm beginning to
> suspect that we could, in fact, come up with a believable resolution
> mechanism for millions of FPIs.

I'm sorry, I wasn't very clear what I wanted when it came to FPIs that
could be treated as URNs.  I would rather say you can use any URN you
like, since they all have the necessary properties of perstance and
uniqueness and being cool that we need than restrict XML to one
particular kind of identifier that might or might not become a URN in
the not too distant future.  If you allow any URN, then if FPIs start
to have a URN resolution mechanism, you can use FPIs, and if they
don't, but sock weaving patterns are used instead, you can use a sock
weaving pattern and get the same result.

Translation of existing SGML FPIs into sock weaving patterns may be
hard, I admit.  But you don't have to do that, because if FPIs are
not made resolvable, are not URNs, then in the URN world they are no
bettwe than system identifiers, as we have no reliable universal
eternal omnipresent inescapable resolution for them (!).  So in that
case you have to use system identifiers, and whether you put them in
a CATALOG or in your instance and look them up in a catalog they are
still system identifiers.  So when you do the other transformations
on your SGML to make it into valid XML -- e.g. changing the syntax
of EMPTY elements to use <GI ATTLIST... />, adding the
<?-XML-?> procinst at the header, normalising OMITTAG and SHORTTAG
usages, removing CONREF elements, normalising SHORTREF and so forth,
you can add Change FPIs into either sock weaving patterns or SYSTEM IDs,
as approriate.  If you do this on the fly at runtime in a server
(presumably with a cache for acceptable performnce), then if FPIs ever
became usable, you could use them.

Your sketch might or might not be workable.  I'm not sure, because
(1) it would have to compete more or less in price with the other
    URN schemes for the user;

(2) it would need to deal with the case where a firm goes out of business
    and no longer pays for its FPIs to be kept in the catalogue (URNs
    have this to deal with too, of course)

(3) it's less glamorous than sock weaving patterns, which could look
    really cool on your screen -- although I am not sure how many
    different socks you can weave with fixed length weaving patterns :-(

But even if it is, why make the restriction?  I think that it makes
us _rely_ on an FPI resolution scheme, whereas allowing URNs would
enable us to _use_ an FPI resolution scheme if one came along, but
any other URN mechanism would also work,

Perhaps the best thing to do is wait six months on this issue, and
see which URN schemes are being deployed successfully.

Lee

Received on Friday, 7 February 1997 21:52:54 UTC