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: New draft published

At 12:10 2001 07 10 -0400, Norman Walsh wrote:
>/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
>| In 6.3, you say that "catalog processors must perform normalization on URI 
>| reference in both the catalog and the input passed to them."  First,
>| "URI reference" -> "URI references".  Next, I think that's wrong as far
>| as "URI reference in...the catalog".  Since you are talking about matching,
>| you must be talking about the lhs, but neither the system nor the URI
>| entry type has a URI reference on the lhs.  Per 6.5.4 and 6.5.8, both 
>| lhs's are things of type "string".  The rhs of both is of type URI ref,
>| but it doesn't make sense to talk of normalizing it.  So this para seems
>| to need rewording.
>I agree that they aren't defined as URI references, but that doesn't
>mean we couldn't mandate performing the character-level URI
>normalization on them.  Are you suggesting we shouldn't? If so, then
>there will be strings that you can put on the LHS that will never,
>ever match. That seems silly. If the idempotent normalization can be
>done on the input string, why not on the catalog string?

I'm not objecting (at least in this comment) to normalizing the lhs, I'm 
objecting to the wording that is not referring to the lhs since it is talking 
about URI refs, and the lhs's are not URI refs.  The wording must be fixed to 
be sure it's referring to the lhs's.

>| In 6.5.3, I see "The URI reference should not include a fragment identifier."
>| I think I keep objecting to this, and maybe I keep getting an answer why I'm
>| wrong, but I have to be reminded one more time, I guess.  Why this restriction?
>The purpose of the public entry is to return a URI for use by the XML
>parser in retrieving a resource. It maps a public identifier to a system
>identifer. XML 1.02e forbids fragment identifiers on system identifiers.
>So if you put a fragid on the RHS of a public entry, you're bound to return
>an invalid system identifier.

But in my view, the catalog isn't returning an system id *to the XML processor*,
it is part of an entity manager.  That entity manager may well be able to handle
a fragment id or a ?xxx query string or whatever, and the entity manager then
returns stuff to be parsed to the XML processor which is none the wiser that there
was a frag id involved at some point.  Specifically, I want to be able to have the
rhs's be queries into an XML data base, for example.

>| In 6.5.4 and 6.5.5 it talks about matching the normalized value of a sysid.
>| Again, I think I'm forgetting something, but this still doesn't make sense
>| to me, esp. since the bit in 6.3 about normalizing made no sense to me.  Why
>The 6.3 bit is taken right from the XML Erratum 78 which I know you've
>suggested should be undone in PE71. Mumble. We did talk about this at
>one or more telcons.

Mumble.  Maybe the wording in 6.3 confused me too much, and I'm okay with
this.  I'll have to think about it again.  Unless you hear from me again
on this, assume I'm okay here.


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

Powered by eList eXpress LLC