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

/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| 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)*.

Cool. I'm not playing the other side of that issue. Nuh-uh. Not me. No
sir. :-)

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

Ah, yes, and that's a good way to refer to them to.

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

Fine by me.

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

No, I'm not implying that at all. I'm saying that if you have a
processor that recognizes includes (of whatever stripe), then you
should use the INCLUDE context when you attempt the xmlcat resolution.

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

Right. Well, actually, it's up to the extension and the processor
that recognizes it to determine what an extension does, but that's
totally outside our scope.

                                        Be seeing you,

Norman.Walsh@East.Sun.COM | Great men too make mistakes, and many among
XML Technology Center     | them do it so often that one is almost
Sun Microsystems, Inc.    | tempted to call them little
                          | men.--Lichtenberg

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

Powered by eList eXpress LLC