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: System URIs


At 07:01 2001 05 25 -0400, Norman Walsh wrote:
>/ Rob Lugt <roblugt@elcel.com> was heard to say:
>| Norman, I see from the archives that you wrote:-
>| 
>| http://lists.oasis-open.org/archives/entity-resolution/200105/msg00171.html
>| 
>| 1) I'm still not absolutely clear about the processing required for the
>| values of the systemId, systemIdStartString, name and uriStartString
>| parameters.  Obviously they will be normalised in the XML 1.0 sense, but I
>| think they should be further normalised to escape illegal URI characters
>| before attempting to match with the value provided from the XML Parser to
>| the EntityResolver.
>
>Yes, this is a good point. I will make the spec clearer.

I agree with making the spec clearer, but I disagree with doing
normalization (except that defined for public ids).  We should
make it clear we are only talking about the standard XML 1.0 
normalization of CDATA attributes.  We should not (and I claim
can not) do any supposed uri-related normalization.  (I claim
that RFC 2396, in fact, does not define any uri normalization.
It does define a process of absolutization, but we are explicitly
not doing that.)

>| 2)  It may be worth pointing out that all parameters that take a value
>| marked "uri-reference" should be normalised in the same way that system
>| identifiers are normalised by XML 1.0 [1].
>
>The systemId, systemIdStartString, name, and uriStartString attributes
>are all going to become type 'string' later this morning. The problem
>with uri-reference is that I believe XML Base would require that
>relative URIs be made absolute with respect to the base in effect and
>that's not desired for those values.

Right, they should all be strings and no normalization applies.


>Mumble. I'm not sure I think it's within our scope to dictate what a
>processor does with system identifiers (or anything else) before it
>asks the catalog processor to resolve them.

I agree that it is outside our scope.  That is, we can't dictate what
applications outside catalog processors do.  But we can suggest that
the right thing to do is to send the string that is in the input document
untouched.  That is the right way to do it.  Far from saying that the 
application should absolutize it first, if anything, I'd point out that
it shouldn't.  But that isn't really within our scope, so at best it
would be a non-normative note.

paul



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


Powered by eList eXpress LLC