j-users@xerces.apache.org
[Top] [All Lists]

Re: Bogus schema generated after multiple invocations of SchemaFactory.n

Subject: Re: Bogus schema generated after multiple invocations of SchemaFactory.newInstanceW3C_...).newSchema(Source[] ...
From: Ron Gavlin
Date: Wed, 20 Sep 2006 04:22:12 -0700 PDT
Michael,
 
Thanks for investigating the problem and resolving it so quickly.
 
Regards,
 
- Ron

----- Original Message ----
From: Michael Glavassevich <mrglavas@xxxxxxxxxx>
To: j-users@xxxxxxxxxxxxxxxxx
Sent: Tuesday, September 19, 2006 4:33:44 PM
Subject: Re: Bogus schema generated after multiple invocations of 
SchemaFactory.newInstance(W3C_...).newSchema(Source[] ...)


Hi Ron,

Now I see what's wrong. This is a bug in the schema loader. When it 
processes schema documents it marks the DOM nodes it has processed as 
"hidden" so that it doesn't revisit them. For input from Xerces' DOM 
implementation it was writing this state directly to the nodes. If the 
same DOM was fed again to the schema loader the nodes were still marked as 
hidden and so weren't being processed.

I just committed a fix to SVN. It will be included in the next release.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@xxxxxxxxxx
E-mail: mrglavas@xxxxxxxxxx

Ron Gavlin <rgavlin@xxxxxxxxx> wrote on 09/18/2006 07:45:51 AM:

> Hi Michael,
> 
> No, the schema I am using has no redefines. I've
> included below the xsd and xml files which I am using
> in my test. Any insight is appreciated.
> 
> - Ron
> 
> XML File:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <phonebook>
>   <enttry>
>     <lastname>Doe</lastname>
>     <firstname>John</firstname>
>       <address type="home">
>         <street>1818 Writer's Lane</street>
>         <city>Lorena</city>
>         <state>TX</state>
>         <zip>76655</zip>
>       </address>
>     </entry>
>   </phonebook>
> 
> XSD Schema File:
> 
> <xsd:schema
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";;>
> 
>   <xsd:complexType name="AddressType">
>     <xsd:sequence>
>       <xsd:element name="street" type="xsd:string"
> maxOccurs="2" />
>       <xsd:element name="city" type="xsd:string" />
>       <xsd:element name="state" type="xsd:string" />
>       <xsd:element name="zip" type="xsd:string" />
>     </xsd:sequence>
>     <xsd:attribute name="type" type="xsd:string" />
>   </xsd:complexType>
> 
>   <xsd:complexType name="EntryType">
>     <xsd:sequence>
>       <xsd:element name="lastname" type="xsd:string"
> />
>       <xsd:element name="firstname" type="xsd:string"
> />
>       <xsd:element name="address" type="AddressType"
> />
>     </xsd:sequence>
>   </xsd:complexType>
> 
>   <xsd:element name="phonebook">
>     <xsd:complexType>
>       <xsd:sequence>
>         <xsd:element name="entry" type="EntryType"
> maxOccurs="unbounded" />
>       </xsd:sequence>
>     </xsd:complexType>
>   </xsd:element>
> 
> </xsd:schema>
> 
> ----- Original Message ----
> From: Michael Glavassevich <mrglavas@xxxxxxxxxx>
> To: j-users@xxxxxxxxxxxxxxxxx
> Sent: Monday, September 18, 2006 12:23:29 AM
> Subject: Re: Bogus schema generated after multiple
> invocations of
> SchemaFactory.newInstance(W3C_...).newSchema(Source[]
> ...)
> 
> 
> Ron Gavlin <rgavlin@xxxxxxxxx> wrote on 09/17/2006
> 11:31:34 PM:
> 
> > Michael,
> > 
> > Thanks for the reply. 
> > 
> > I've included my complete test program below. The
> test only works 
> > with the Xerces XMLSchemaFactory if I clone the
> schema document 
> > element each time before it is wrapped by a
> DOMSource. Is this the 
> > expected behavior? I find it interesting that the
> JDK 1.5 
> > SchemaFactory does not require the schema document
> element to be 
> > cloned? Can you explain the discrepancy?
> 
> Are you using redefine in your schema? If so the
> schema loader is probably 
> mutating the input DOM. That's a bug which hasn't been
> fixed yet.
> 
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@xxxxxxxxxx
> E-mail: mrglavas@xxxxxxxxxx
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> j-users-unsubscribe@xxxxxxxxxxxxxxxxx
> For additional commands, e-mail:
> j-users-help@xxxxxxxxxxxxxxxxx
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xxxxxxxxxxxxxxxxx
> For additional commands, e-mail: j-users-help@xxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: j-users-help@xxxxxxxxxxxxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: j-users-help@xxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>