I have been made aware of a bug in Xerces 2.6.2 on JRE 1.5.0_18:

According to source code comments there is a bug in xerces that prevents it from parsing schemas with imports and includes correctly:

Xerces (used by JAXP in Java 1.5 and later) does not correctly parse composite schema,
(i.e. schema containing <import> and <include> elements) unless the schema are first written
to disk files.  Writing schema to disk files, forces us to re-write each <import> and <include>
element's schemalocation attribute to reference disk files instead.

I have been searching the Bugzilla reports to determine whether this has been fixed or even ever reported, but I cannot find anything that seems directly related. I just wanted to know if this has been fixed between 2.6.2 and the current version, as an upgrade would obviously be the simplest fix, or if it needs to be reported.

Thank you.

Hi Michael,

Hi there,

govelogo <govelogo <at> gmail.com> wrote on 07/03/2009 10:44:17 AM:

> Hi there,
>
> I am running the jaxp.TypeInfoWriter to parse a xml. For one
> element, I got this result,
>
>       startElement(name="{http://crm.testschema.
> ca/xml/as/ServiceAndOfferMapping/v1-0}associatedWithServices",type="{
> http://crm.testschema.ca/xml/as/ServiceAndOfferMapping/v1-0}
> #AnonType_associatedWithServicesInstalledProductOfferingValueType",qname="
> saom:associatedWithServices",attributes={})
>
> inside the ServiceAndOfferMapping (saom) .xsd,
> "associatedWithServices" is defined here as below, (the schema for
> cbeservice-v1-5 is "http://ossj.org/xml/Common-CBEService/v1-5")
>
> <xs:complexType name="InstalledProductOfferingValueType">
> <xs:complexContent>
> <xs:extension base="cbeproductoffering-v1-5:ProductOfferingValue">
> <xs:sequence>
> <xs:element name="associatedWithServices" minOccurs="0">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="cbeservice-v1-5:ArrayOfServiceKey"/>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> <xs:element name="serviceAndOfferMapping" type="saom:
> ServiceAndOfferMappingType"/>
>
> My question is why the type name is not shown as the base type (
> cbeservice-v1-5:ArrayOfServiceKey), but rather like a garbage string
> (in red color)?

Because the base type is not its type. The type of "associatedWithServices" actually has no name. It's anonymous, however the API [1] you're using requires that implementations produce an "anonymous type name" [2] to uniquely identify the anonymous type and that is what you're getting.

> many thanks,
> David

[1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#TypeInfo
[2] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/glossary.html#dt-anonymous

Thanks.

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

govelogo <govelogo <at> gmail.com> wrote on 07/03/2009 12:39:55 AM:

> Hi Michael,
>
> I thought this would solve my problem. But I run into an order issue. 
>
> What I want is to be able to match from a uri to its prefix while
> parsing through an xml. It seems startPrefixMapping() is paired
> with startElement(). So if there is a xsi:type attribute of the
> element pointing to a new type yet been parsed, I won't be able to
> find the prefix in the uri -> prefix hashtable I have been keep tracking.

Um... why not? The startPrefixMapping() calls come first. You should always have all the information you need to do prefix -> uri mapping on any startElement().

> It seems to me that a SAX parser may not work for what I want. Is
> there a sample using a DOM parser to traverse a DOM tree and still
> be able to use JAXP to get TypeInfo and ElementPSVI?

There are plenty of samples, FAQs and articles which show how to use or talk about how to use these things in isolation, but you'd probably have to connect the dots yourself.

> thanks a lot,
> David

Thanks.

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

... and the usual disclaimer. What ships in Java 5 is Sun's fork of the Xerces codebase. It is not Xerces 2.6.2 or any other Apache version for that matter. All sorts of changes and additions were made to it since it branched from the Apache code that we are not aware of and have no influence over. It is known to have issues which are unique to it and others which have long been fixed in Xerces. If you need assistance with this codebase the Sun forums are a more appropriate place for discussion.

Thanks.

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

jeff.greif <at> gmail.com wrote on 07/02/2009 02:21:20 AM:

> You can put any URI you want into the location attribute on import or
> include, and resolve it from schemas held in strings or relational
> databases or resources in a jar file or anything else, if you provide
> an EntityResolver to the parser.  See
> DocumentBuilder.setEntityResolver().
>
> You can also use set a property on the parser to specify a set of
> schema locations.  The property is
> http://apache.org/xml/properties/schema/external-schemaLocation and
> its value is a string containing an alternating series of namespace
> followed by location-URI.  This can be combined with the use of an
> EntityResolver.
>
> If you use the non-JAXP parsers provided by Xerces, you can specify an
> XMLEntityResolver.  This is passed an XmlResourceIdentifier, which,
> for a needed XML schema, will include the target namespace of the
> schema.  You can build an XmlEntityResolver which uses some arbitrary
> technique to resolve schema namespaces to the source text.
>
> Jeff
>
> On Wed, Jul 1, 2009 at 2:24 PM, Grubaugh,
> Eric-p65363<Eric.Grubaugh <at> gdc4s.com> wrote:
> > I have been made aware of a bug in Xerces 2.6.2 on JRE 1.5.0_18:
> >
> > According to source code comments there is a bug in xerces that prevents it
> > from parsing schemas with imports and includes correctly:
> >
> > Xerces (used by JAXP in Java 1.5 and later) does not correctly parse
> > composite schema,
> > (i.e. schema containing <import> and <include> elements) unless the schema
> > are first written
> > to disk files.  Writing schema to disk files, forces us to re-write each
> > <import> and <include>
> > element's schemalocation attribute to reference disk files instead.
> >
> > I have been searching the Bugzilla reports to determine whether this has
> > been fixed or even ever reported, but I cannot find anything that seems
> > directly related. I just wanted to know if this has been fixed between 2.6.2
> > and the current version, as an upgrade would obviously be the simplest fix,
> > or if it needs to be reported.
> >
> > Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe <at> xerces.apache.org
> For additional commands, e-mail: j-users-help <at> xerces.apache.org

Hi Michael,