[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: do we dig under the fence with pseudo-public ids...
Paul Grosso scripsit: > We can delegate system ids, we can delegate URIs, what is the > advantage of having two completely different ways to provide > "-//Acme//DTD Book//EN" as the left hand side of a catalog > lookup process? Are you questioning the point of urn:publicid: altogether? If not, we already *have* two ways to provide "-//Acme//DTD Book//EN". We can either require that catalog writers keep around multiple mapping/delegating entries: one for the public id "-//Acme//DTD Book//EN"; one for the public id "urn:publicid:-:Acme:DTD+Book:EN"; one for the system id (ditto); one for the URI (ditto). Or we can bite the bullet and say that any string beginning "urn:publicid:" is a public id, never mind the formalities of how it got to us. Indeed, just to be difficult, why are we allowing and indeed requiring separate mappings for system ids and random URIs? A system id *is* a random URI. I have never seen a clear justification for this dual mechanism. -- There is / one art || John Cowan <jcowan@reutershealth.com> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC