Re: Catalog Requirements

[Terry Allen <tallen@sonic.net>]

with message body this time ...

Paul re Norm:
| At 12:20 2000 11 17 -0500, Norman Walsh wrote:
| >/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| >| At 14:03 2000 11 16 -0800, Terry Allen wrote:
| >| >Paul wrote:
| >| >| But URI is orthogonal to PUBLIC, SYSTEM, etc., and it going to be 
| >| >| a mess.  I don't want to go there.  
| >| >
| >| >Okay.  We do need URI>URI mapping, though. 
...

[Norm:] 
| >(I can play both sides of this issue, just watch me :-)
| >
| >While it would be easy and convenient to constrain our work only to
| >the narrow cases that arise from entity management in XML (which in
| >turn are a subset of the cases that arise in SGML), I'm not sure we're
| >going to do our community a lot of good if we take that narrow a view.
| >
| >It seems likely that not-to-distant XML systems will have no remains
| >of DTD syntax at all. We need to provide a little more support for
| >those systems.
| >
| >Just as traditional entity management has classes of identifiers (what
| >Paul calls functional classes, I think), XML systems have classes of
| >identifiers. The classes that spring to mind for XML are
| >
| >  SYSTEM
| >  PUBLIC
| >  NAMESPACE
| >  SCHEMALOC
| >  STYLESHEET
| >  INCLUDE

These are not classes of identifiers, except maybe for SYSTEM and
PUBLIC, they are classes of things identified.  If I hadn't agreed
with Paul that it's out of scope, I would argue that the class of
a thing identified should make no difference to how its identifier
is mapped.  Aside from a DTD used in parsing and also displayed
(having been referenced as an entity), I can't think of a case
where the same identifier is used for the same item in different 
functional classes - because it's irrelevant to the functionality
of an identifier what it identifies.

[Paul:]
| We're not disagreeing--what you've defined above are functional classes,
| and while we can debate which of the above should go into our version 1
| xmlcat, we're still within scope because a given string-in-context that 
| is input to the resolution mechanism is only going to satisfy one of
| those contextual/functional classes.

This is the converse (that in fact in SGML identifiers occur in
contexts that limit them to functional classes), and something
we have to deal with.  So my view of how things should be is
out of scope.  Charles got there first.

| What I claim is out of scope and a bad idea is to try to have some
| kind of "URI" entry that maps something *because it is a URI (regardless
| of its context/function)*.

Not "because it is a URI", but "regardless of its context or function".

| >If we provide URI/URI mappings for these classes, 
| 
| Well, it's not a URI-to-URI mapping; the righthand side is a 
| string-in-XML-context which might often be interpretable as
| a URI, but that's besides the point.

This is an excellent point, which shows why I shouldn't try to
do URI>URI mapping in the xmlcat.  Even if I think the socat
is wifty in this regard.
...

[Norm:]
| >Terry, you're going to hate this :-), but I suggest that
| >application-specific mappings should occur in the xmlcat in a
| >different namespace.

If you apply "XML namespaces" to the xmlcat such that it 
cannot be used without them, then it's useless to me.  And it
would certainly be useless for URI>URI mapping.  And I would
probably stop paying attention ...

regards, Terry