[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. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC