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: YAD 25 May 2001


At 10:54 2001 05 25 -0400, Norman Walsh wrote:
>Yet another draft[1], in response to ER-comments. The diff's pretty clear.
>Comments, please.

In various places you have:

  If the value of the uri attribute is relative, it must be
  made absolute with respect to the xml:base currently in effect.

I'd prefer:

  ...with respect to the base URI currently in effect.

You have already said previously:
  The xml:base attribute changes the base URI....

The problem with the current wording is that it doesn't cover
the case in the absence of xml:base, but it is still the case
then that the relative uri must be made absolute per the base URI.

-----------------------

You have:

  Before comparing system identifiers, the value of the
  systemId attribute must be normalized according to the rules of
  [RFC 2396] with respect to URI comparison and character escaping.

Actually, I thought we decided just the opposite the other day when
we discussed this.  I even remember saying that, if the string had,
say, backslashes instead of forward slashes, you'd just compare that
as is.  I thought we just compared system and uri entries as strings,
doing nothing to the lefthand sides (or the string passed in) before
comparison.  I thought it was only the public entry's left hand side
(and passed in public id) that were normalized (per the public id
normalization process) before comparison.

So I'd like to reopen this issue, I guess, sigh.  Sorry, but I was
pretty sure this was discussed and decided differently from what
the spec has.

Note that I don't agree that RFC 2396 defines a normalization.
It does "normalize" some things like "../" as part of the defined
absolutization process, but we are explicitly not doing absolutization.
For example, if someone has "foo\bar.xml" in the document and 
"foo/bar.xml" in the left hand side of a catalog's system entry,
these will NOT match.  Pretending/attempting to do any normalization
before comparison of left hand sides (except in the case of public ids)
is a bad idea in my opinion, and I'd like the spec changed to make it
clear that there is no normalization (other than the inevitable XML 1.0
attribute normalization) done on either the input string or the catalog
entries' left hand sides (other than for public ids).

paul



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


Powered by eList eXpress LLC