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: Catalog Requirements

At 08:51 2000 11 16 -0800, Norman Walsh wrote:
>/ Terry Allen <tallen@sonic.net> was heard to say:
>| What bad happens if we just add a URI>URI function?  (I don't
>| know, I'm asking to see whether the simplest solution would 
>| work.)
>I don't know that anything bad happens, but I have three concerns.

I share Norm's concerns.

Furthermore, I would elaborate on what I'd call the function vrs syntax
issue.  That is, all of PUBLIC, SYSTEM, and other catalog entry types
are functional.  That is, in each case, the lefthand side is a string
in context.  For example, "xxx" could be a public id, a system id, an
entity name, etc., but what "xxx" represents is clear from looking at
the catalog entry in which it appears.  

Once you start to have a URI entry type, you are allowing something
whose function is unclear to be mapped.  When you call an entity
resolver, you come in with an external entity declaration and you
know that you've got X for the entity name, Y for the public id,
and Z for the system id, and TR9401 carefully defines how to do
the catalog lookup.  

But URI is orthogonal to PUBLIC, SYSTEM, etc., and it going to be 
a mess.  I don't want to go there.  I could see a NAMESPACE entry
type and a STYLESHEET type (though I'm not sure I'd really want
them, but at least they remain functional and non-orthogonal), but
I cannot see how URI is going to fit unambiguously into the catalog
lookup paradigm, and I do not wish to complicate things in that way.


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

Powered by eList eXpress LLC