Re: Crimson 1.1.3 tests

Thanks for the backgrounder, I've put some comments in-line with your
original message.

----- Original Message -----
From: "David Brownell" <david-b@pacbell.net>
To: "Curt Arnold" <carnold@houston.rr.com>
Cc: "Edwin Goei" <edwingo@sun.com>; <www-dom-ts@w3.org>
Sent: Friday, November 16, 2001 12:47 AM
Subject: Re: Crimson 1.1.3 tests


> The deal is that SAX clearly specifies that those IDs are supposed to
> be resolved, so that's how Crimson does it.  (Xerces just as clearly
> violates the SAX spec in this area.  See the "saxunit 0.2" tests now
> available at http://xmlconf.sourceforge.net ...)  I suspect that if you
had
> included the GNUJAXP software you'd find it also resolves those
> URIs.  (What test software were you running?  The "domunit 0.0.6"
> test cases don't address such issues.)

ca: The NIST/W3C DOM Test Suite stuff in the W3C CVS (see
http://www.w3.org/dom/test).  Requires Ant 1.4 (exactly) with Crimson
replaced (sorry) with Xalan-J 2.1 (again exactly) and the corresponding
Xerces to build, if you are interested.

DOMUnit did have testNotationGetSystemId which accepted either a relative or
absolute URI.

>
> If you want rationales, I'll share two beyond "it's allowed and
> conforms with the specs".

CA: Isn't done by most processors
and may come as a surprise to even knowledgable practitioners.
Therefore should be worth at least a mention that
absolutizing may occur since it seems rare in current practice (Crimson
being
the only implementation that I've seen that does it)

> First, the original expectation with XML
> was that as "SGML on the web", all system IDs would be URLs.
> And second, since DOM levels 1 and 2 don't expose information
> about the base URLs of nodes, it'd seem that ever exposing relative
> URLs through DOM would be buglike.  I know there were some
> discussions early in the L2 timeframe about exposing those bases,
> but that never happened.
>
> Was there some rationale available for DOM implementations
> that chose to expose relative URIs while hiding the base URIs
> needed to interpret them?

[ca] Probably so you could serialize a document without having
the system id's obviously mucked with.  Probably a fair number
of entity resolvers that examine the systemId would fail to work
if the source document had a unexpectedly absolutized systemId.
Of course, that is a consequence of using the systemId to perform
publicId's role.

>
>
> FYI, there's now a SAX feature flag defined to control how those
> IDs get handled:
>
>     http://xml.org/sax/features/resolve-dtd-uris
>
> See the listing of such flags
>
>     http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html
>
> Some of those IDs support "SAX extensions 1.1", which I may put
> out as a "beta" release soon.  (All the RFEs have been answered.)
>
> - Dave
>

With SAX making the behavior switchable and since many DOM implementations
are layers on SAX, that makes it pretty clear that mandating absolutizing in
the tests isn't
acceptible either.

I've removed the verbatim systemId assertions in the two tests in the DOM L1
Core suite (leaving an assertion that just checks if the filename fragments
are the same) and changed the verbatim systemId assertions in the DOM L2
tests (main the import*.xml tests).

Received on Friday, 16 November 2001 03:20:30 UTC