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: XML Catalog issue 16


At 14:36 2001 03 19 -0500, John Cowan wrote:
># In XML, every external identifier has a system identifier (it may
># also have a public identifier). Delegate processing, as currently
># defined, would effectively discard the system identifier for
># processing the delegated-to catalog. This may not be the right
># thing in XML.
>
>I think it is important to be able to convert 9401 catalogs to
>XML Catalogs 1-1, without requiring massive and unfeasible searches
>through catalog space.  That requires that 9401 semantics be
>preserved exactly.
>
>9401 semantics require that when a catalog has been reached via a
>DELEGATE entry, that any SYSTEM entries it contains are of no
>effect.  If this property is not preserved, it will be necessary to
>split any catalog that *might* be reached via DELEGATE into two
>versions, one with and one without SYSTEM.  Keeping these two
>in sync would be unreasonably difficult.
>
>Therefore I propose that we not change the existing 9401-compatible
>semantics.

Not only do I definitely agree, but I think our requirements for
9401 compatibility requires this.  Finally, I don't see the problem
here--why was this ever an issue?

By the way, if/when we delegate system ids, we will have an analogous 
situation in that we will ignore the public id when we are trying to
resolve the system id in a delegated-to catalog.

paul



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC