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: SAX 2.0 enhancement proposal


From Norm Walsh:
> / David Brownell <david-b@pacbell.net> was heard to say:
> [...]
> | The XML spec is quite explicit on this topic: "relative URIs are
> | relative to the location of the resource within which the entity
> | declaration occurs" (4.2.2).
> 
> I don't believe that assertion is in question, however, Section
> 4.2.2. says:
> 
>   [Definition: ...

Yep, I've read all that quite a few times.


> Note that it says "meant to be dereferenced". It does not say "must"
> be dereferenced.

Dereferencing isn't the same thing as relative URI interpretation,
so I don't see how that relates.  I'm not talking about details of
how the identifiers get used after relative URIs are interpreted:

   "relative URIs are relative to the location of the resource within
    which the entity declaration occurs"

That doesn't imply dereferencing of anything except some identifier
which clearly had to already have been dereferenced (for the entity
which held the declaration).

Once the relative URI is interpreted relative to that location,
it's open season -- map the ID to /dev/null, to NUL:, to an error,
to a local cache, to whatever.  But that's AFTER it's been
interpreted relative to the location of the resource etc.


> I believe it is entirely consistent for the entity resolution
> mechanism to be considered information outside the scope of this
> specification.

But the interpretation of the relative URIs is WITHIN scope of
the XML spec, and it says something very specific, quoted above.
I don't see how using any other mechanism could be consistent
with that clear language.


> | Those are the only contexts in which an XML parser needs to resolve
> | URIs, and there's no weasel-wording that would allow what that
> | catalog spec is intending to do.  So I don't see why SAX should
> | permit anything else, unless the XML spec gets a substantive
> | functional change there ...
> 
> I don't understand your conclusion at all. ...

And I don't see why you don't understand, except that my conclusion
doesn't agree with your desired outcome.


> If the system identifier that the parser finally winds up using is a
> relative URI reference, it's clear that it's relative to the base URI
> of the containing entity. As I said before, I don't think that's in
> dispute.

But the purpose of that proposed change is exactly to dispute that ... :)
It's to enable interpretation with respect to something else.  If it weren't,
then no change would be necessary.  QED.

- Dave




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


Powered by eList eXpress LLC