You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by ca...@emc.com on 2011/03/08 16:15:48 UTC

Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0

Hi,

When parsing an XML document "personal-schema.xml" with xsi:noNamespaceSchemaLocation="personal.xsd" with the code below, I get different systemId parameter values in the LSResourceResolver in version 2.11.0 and 2.10.0 :

    DOMImplementationLS implementationLS = new DOMImplementationImpl();
    LSParser builder = implementationLS.createLSParser(DOMImplementationLS.MODE_SYNCHRONOUS, null);

    LSResourceResolver resolver = new LSResourceResolver() {

      public LSInput resolveResource(String type, String namespace, String publicId,
          String systemId, String baseURI) {
        // in Xerces 2.11.0, systemId is expanded: 'file:/C:/my/path/to/doc/personal.xsd'
        // in Xerces 2.10.0, the value is exactly the same as declared in the document: 'personal.xsd'
        return null;
      }
    };

    builder.getDomConfig().setParameter("validate", Boolean.TRUE);
    builder.getDomConfig().setParameter("resource-resolver", resolver);
    Document doc = builder.parseURI(getURL("personal-schema.xml").toString());

Is this a bug?

Thanks!
Carla

RE: Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0

Posted by ca...@emc.com.
Hi Michael,

Thanks!

Carla

From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
Sent: 09 March 2011 13:49
To: j-users@xerces.apache.org
Subject: RE: Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0


Hi Carla,

Based on what was changed for XERCESJ-809 that's what I would expect to see for xsi:noNamespaceSchemaLocation and xsi:schemaLocation hints in the document. They get loaded at some point later if they're required and Xerces (2.10.0) would sometimes use the wrong base URI due to the load request being in some other context than processing of the main document. Expansion of the URI before it's cached in an internal map solved that problem, but would have also introduced this behavioural change to the entity resolver.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

<ca...@emc.com> wrote on 03/09/2011 04:48:17 AM:

> Hi Michael,
>
> Thank you for the answer. I can see why this is changed.
>
> Just to be sure. I also see that when using the
> org.apache.xerces.xni.XMLEntityResolver and function resolveEntity
> (XMLResourceIdentifier resourceIdentifier), the value of
> resourceIdentifier.getLiteralSystemId() is now equal to
> resourceIdentifier.getExpandedSystemId(). The original location
> value found in the XML document or schema is no longer available in
> XMLResourceIdentifier.
>
> Thanks,
> Carla
>
> From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
> Sent: 09 March 2011 06:08
> To: j-users@xerces.apache.org
> Subject: Re: Different behavior entity resolver Xerces 2.11.0 and
> Xerces 2.10.0
>
> Hi Carla,
>
> The change in behaviour is most likely due to the fix for this JIRA
> issue [1]. From a quick glance at the DOM Level 3 Load & Save spec
> [2] I didn't see anything which forbids expansion of the system ID
> before reporting it.
>
> Thanks.
>
> [1] https://issues.apache.org/jira/browse/XERCESJ-809
> [2] http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSResourceResolver
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> <ca...@emc.com> wrote on 03/08/2011 10:15:48 AM:
>
> > Hi,
> >
> > When parsing an XML document "personal-schema.xml" with
> > xsi:noNamespaceSchemaLocation="personal.xsd" with the code below, I
> > get different systemId parameter values in the LSResourceResolver in
> > version 2.11.0 and 2.10.0 :
> >
> >     DOMImplementationLS implementationLS = new DOMImplementationImpl();
> >     LSParser builder = implementationLS.createLSParser
> > (DOMImplementationLS.MODE_SYNCHRONOUS, null);
> >
> >     LSResourceResolver resolver = new LSResourceResolver() {
> >
> >       public LSInput resolveResource(String type, String namespace,
> > String publicId,
> >           String systemId, String baseURI) {
> >         // in Xerces 2.11.0, systemId is expanded: 'file:/C:/my/
> > path/to/doc/personal.xsd'
> >         // in Xerces 2.10.0, the value is exactly the same as
> > declared in the document: 'personal.xsd'
> >         return null;
> >       }
> >     };
> >
> >     builder.getDomConfig().setParameter("validate", Boolean.TRUE);
> >     builder.getDomConfig().setParameter("resource-resolver", resolver);
> >     Document doc = builder.parseURI(getURL("personal-
> schema.xml").toString());
> >
> > Is this a bug?
> >
> > Thanks!
> > Carla

RE: Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0

Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Carla,

Based on what was changed for XERCESJ-809 that's what I would expect to see
for xsi:noNamespaceSchemaLocation and xsi:schemaLocation hints in the
document. They get loaded at some point later if they're required and
Xerces (2.10.0) would sometimes use the wrong base URI due to the load
request being in some other context than processing of the main document.
Expansion of the URI before it's cached in an internal map solved that
problem, but would have also introduced this behavioural change to the
entity resolver.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

<ca...@emc.com> wrote on 03/09/2011 04:48:17 AM:

> Hi Michael,
>
> Thank you for the answer. I can see why this is changed.
>
> Just to be sure. I also see that when using the
> org.apache.xerces.xni.XMLEntityResolver and function resolveEntity
> (XMLResourceIdentifier resourceIdentifier), the value of
> resourceIdentifier.getLiteralSystemId() is now equal to
> resourceIdentifier.getExpandedSystemId(). The original location
> value found in the XML document or schema is no longer available in
> XMLResourceIdentifier.
>
> Thanks,
> Carla
>
> From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
> Sent: 09 March 2011 06:08
> To: j-users@xerces.apache.org
> Subject: Re: Different behavior entity resolver Xerces 2.11.0 and
> Xerces 2.10.0
>
> Hi Carla,
>
> The change in behaviour is most likely due to the fix for this JIRA
> issue [1]. From a quick glance at the DOM Level 3 Load & Save spec
> [2] I didn't see anything which forbids expansion of the system ID
> before reporting it.
>
> Thanks.
>
> [1] https://issues.apache.org/jira/browse/XERCESJ-809
> [2]
http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSResourceResolver
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> <ca...@emc.com> wrote on 03/08/2011 10:15:48 AM:
>
> > Hi,
> >
> > When parsing an XML document "personal-schema.xml" with
> > xsi:noNamespaceSchemaLocation="personal.xsd" with the code below, I
> > get different systemId parameter values in the LSResourceResolver in
> > version 2.11.0 and 2.10.0 :
> >
> >     DOMImplementationLS implementationLS = new DOMImplementationImpl();
> >     LSParser builder = implementationLS.createLSParser
> > (DOMImplementationLS.MODE_SYNCHRONOUS, null);
> >
> >     LSResourceResolver resolver = new LSResourceResolver() {
> >
> >       public LSInput resolveResource(String type, String namespace,
> > String publicId,
> >           String systemId, String baseURI) {
> >         // in Xerces 2.11.0, systemId is expanded: ?file:/C:/my/
> > path/to/doc/personal.xsd?
> >         // in Xerces 2.10.0, the value is exactly the same as
> > declared in the document: ?personal.xsd?
> >         return null;
> >       }
> >     };
> >
> >     builder.getDomConfig().setParameter("validate", Boolean.TRUE);
> >     builder.getDomConfig().setParameter("resource-resolver", resolver);
> >     Document doc = builder.parseURI(getURL("personal-
> schema.xml").toString());
> >
> > Is this a bug?
> >
> > Thanks!
> > Carla

RE: Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0

Posted by ca...@emc.com.
Hi Michael,

Thank you for the answer. I can see why this is changed.

Just to be sure. I also see that when using the org.apache.xerces.xni.XMLEntityResolver and function resolveEntity(XMLResourceIdentifier resourceIdentifier), the value of resourceIdentifier.getLiteralSystemId() is now equal to resourceIdentifier.getExpandedSystemId(). The original location value found in the XML document or schema is no longer available in XMLResourceIdentifier.

Thanks,
Carla

From: Michael Glavassevich [mailto:mrglavas@ca.ibm.com]
Sent: 09 March 2011 06:08
To: j-users@xerces.apache.org
Subject: Re: Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0


Hi Carla,

The change in behaviour is most likely due to the fix for this JIRA issue [1]. From a quick glance at the DOM Level 3 Load & Save spec [2] I didn't see anything which forbids expansion of the system ID before reporting it.

Thanks.

[1] https://issues.apache.org/jira/browse/XERCESJ-809
[2] http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSResourceResolver

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

<ca...@emc.com> wrote on 03/08/2011 10:15:48 AM:

> Hi,
>
> When parsing an XML document "personal-schema.xml" with
> xsi:noNamespaceSchemaLocation="personal.xsd" with the code below, I
> get different systemId parameter values in the LSResourceResolver in
> version 2.11.0 and 2.10.0 :
>
>     DOMImplementationLS implementationLS = new DOMImplementationImpl();
>     LSParser builder = implementationLS.createLSParser
> (DOMImplementationLS.MODE_SYNCHRONOUS, null);
>
>     LSResourceResolver resolver = new LSResourceResolver() {
>
>       public LSInput resolveResource(String type, String namespace,
> String publicId,
>           String systemId, String baseURI) {
>         // in Xerces 2.11.0, systemId is expanded: 'file:/C:/my/
> path/to/doc/personal.xsd'
>         // in Xerces 2.10.0, the value is exactly the same as
> declared in the document: 'personal.xsd'
>         return null;
>       }
>     };
>
>     builder.getDomConfig().setParameter("validate", Boolean.TRUE);
>     builder.getDomConfig().setParameter("resource-resolver", resolver);
>     Document doc = builder.parseURI(getURL("personal-schema.xml").toString());
>
> Is this a bug?
>
> Thanks!
> Carla

Re: Different behavior entity resolver Xerces 2.11.0 and Xerces 2.10.0

Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Carla,

The change in behaviour is most likely due to the fix for this JIRA issue
[1]. From a quick glance at the DOM Level 3 Load & Save spec [2] I didn't
see anything which forbids expansion of the system ID before reporting it.

Thanks.

[1] https://issues.apache.org/jira/browse/XERCESJ-809
[2]
http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSResourceResolver

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

<ca...@emc.com> wrote on 03/08/2011 10:15:48 AM:

> Hi,
>
> When parsing an XML document "personal-schema.xml" with
> xsi:noNamespaceSchemaLocation="personal.xsd" with the code below, I
> get different systemId parameter values in the LSResourceResolver in
> version 2.11.0 and 2.10.0 :
>
>     DOMImplementationLS implementationLS = new DOMImplementationImpl();
>     LSParser builder = implementationLS.createLSParser
> (DOMImplementationLS.MODE_SYNCHRONOUS, null);
>
>     LSResourceResolver resolver = new LSResourceResolver() {
>
>       public LSInput resolveResource(String type, String namespace,
> String publicId,
>           String systemId, String baseURI) {
>         // in Xerces 2.11.0, systemId is expanded: ?file:/C:/my/
> path/to/doc/personal.xsd?
>         // in Xerces 2.10.0, the value is exactly the same as
> declared in the document: ?personal.xsd?
>         return null;
>       }
>     };
>
>     builder.getDomConfig().setParameter("validate", Boolean.TRUE);
>     builder.getDomConfig().setParameter("resource-resolver", resolver);
>     Document doc = builder.parseURI(getURL
("personal-schema.xml").toString());
>
> Is this a bug?
>
> Thanks!
> Carla