OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[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