Re: Catalog Requirements

[Paul Grosso <pgrosso@arbortext.com>]

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.  Let's imagine it
>| >happens through (some piece of some processor) consulting another 
>| >map.  (If anyone wants references to previous URN-WG work on
>| >such maps, let me know.)
>| 
>| Careful that you don't mix layers.  Without getting into the
>| discussion of whether URI>URI mapping is good or bad, it is
>| not part of XML entity management and does not belong mixed
>| in with an entity management catalog.
>
>(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

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.

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)*.

>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.

>I think we'll be
>near the 80/20 point. (INCLUDE, btw, is for things like <xsl:include>,
><xsd:include>, and <xml:include>. But if we decided that those were
>SYSTEM identifiers, I could live with that, too.)

We probably could, but I'd argue that they're system identifiers 
only if that match a certain production in XML 1.0 that says so, 
and they don't.  So if we're going to match such thingies in 
include statements, I'd argue we should have a special entry type.

(Of course, now you're implying that support of xmlcat implies
recognition of <xsd:include> and <xsl:include>, which means
existing XML 1.0+namespace processors couldn't fully support
version 1 of xmlcat which would be a disappointment to me.)

>| >What piece of what processor would we like it to be, and should
>| >the mapping be done before or after the xmlcat is consulted,
>| >or both?  and should the two items (URI map and xmlcat) be
>| >consulted by the XML processor or by some new, specialized
>| >processor that feeds its results into the XML processor?
>| >
>| >or something else?
>
>For the functional classes that we identify, I think the xmlcat
>processor should be consulted. For application-specific purposes, I
>think a specialized xmlcat processor should be used, one that
>recognizes your extensions to the xmlcat.

Right, but that's not URI-to-URI mapping as I've discussed it.

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

Again, if you're talking about application-specific contexts,
that would be okay using some extension mechanism in xmlcat,
but this is still not "map this URI regardless of its context
into that URI" which is a kind of redirection that belongs at
a lower level than xmlcat.

paul