Re: Catalog Requirements

[Paul Grosso <pgrosso@arbortext.com>]

At 18:00 2000 11 19 -0800, Lauren Wood wrote:
>On 16 Nov 2000, Terry Allen wrote:
>
>> I don't believe I am mixing layers; I believe that the contextual
>> semantics (e.g., SYSTEM vs PUBLIC vs ENTITY) of the socat are obsolete 
>> and that the 2 mapping problems are at exactly the same layer.  But I
>> accept your argument that URI>URI mapping is out of scope for
>> this TC, so I won't press the point.  
>
>I don't accept this. I think URI>URI mapping is in scope; one 
>example is the href URI on the stylesheet PI for which we have no 
>solution currently (it's not a SYSTEM ID). This is an example of the 
>new XML features which are part of our statement of purpose.

I think we are closer to agreeing on what we want but disagreeing
on vocabulary.

If you want to map the thing in a stylesheet PI, then we should
add a STYLESHEET entry type.  That is functional/contextual.  We
are not mapping arbitrary URIs (which I still think is out of scope).

Maybe an example would help explain what I'm saying.

document instance
-----------------

<?xml version="1.0"?>
<!DOCTYPE foo PUBLIC "xxx" "yyy" [
<!ENTITY bar SYSTEM "xxx">
<?xml-stylesheet href="xxx" type="text/css"?>
]>
<foo xmlns="xxx">
&bar;
</foo>

possible catalog
----------------
PUBLIC		"xxx"	"foo.dtd"
SYSTEM		"xxx"	"bar.xml"
STYLESHEET	"xxx"	"stylesheet.css"
NAMESPACE	"xxx"	"foo namespace name"
URI		"xxx"	"huh?"

Note that there are four occurrences of the URI "xxx" in
the document instance and four corresponding entries in
the catalog without there being any ambiguity as to which
entry is applicable in each case.  This is what I'm calling
functional/contextual mapping.  Sure the left hand side
might be a URI (or might not), but this isn't pure, context
free URI>URI mapping which I claim is out of scope in an
entity management catalog (and, in fact, belongs in a lower
layer, because one may well want to remap the URI that comes
*out* of a catalog mapping).

I hope my example makes clear why the last entry in the catalog 
above is ambiguous and problematic, and it isn't needed to address 
anything we really have to do in xmlcat version 1.0.

paul