[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: SAX 2.0 enhancement proposal
With the work being performed by the OASIS Entity Resolution TC [1], attention is being focused on resolving entities using XML Catalogs. An obvious way to implement catalog processing is by providing a custom SAX EntityResolver. However, the SAX 2.0 specification [2] puts an impediment in the way of a conforming implementation. I'll explain why... The XML Catalog draft specification [3] describes several different entry types. Some entries are for resolving public identifiers, some are for resolving system identifiers. The system identifier entries are intended to be matched with the system identifier as it appears in the xml document being processed. Unfortunately, SAX 2.0 requires that system identifiers that are URIs are made absolute before calling the EntityResolver, thereby robbing the catalog processor of the opportunity to compare the system identifier with the catalog entries. In my view, an improved EntityResolver interface (perhaps for SAX 3.0) would be : interface EntityResolver { public InputSource resolveEntity(java.lang.String name, java.lang.String publicId, java.lang.String systemId, java.lang.String baseUri) throws SAXException, java.io.IOException; } This would give the EntityResolver everything it needs to do the job. If it wanted to absolutize the system identifier then it could do so, but it would also have access to the bare value. Of course I realise that this is not practical for SAX 2.0, and we don't want to wait for SAX 3.0 before implementing conforming and portable XML Catalog processors under SAX. I propose a simple extension to SAX 2.0 in the guise of a new standard feature: http://xml.org/sax/features/absolutize-system-identifiers. The default value could be "true" to maintain compatibility with existing systems. Applications could set it to "false" when they want a conforming catalog processor. Anybody agree, disagree or indifferent? Regards Rob Lugt ElCel Technology http://www.elcel.com/ [1] http://www.oasis-open.org/committees/entity/ [2] http://www.megginson.com/SAX/Java/javadoc/index.html [3] http://www.oasis-open.org/committees/entity/spec-2001-06-12.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC