DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15248>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15248 SymbolTable can't resolve element refs in schemas with complexContent restrictions ------- Additional Comments From [EMAIL PROTECTED] 2002-12-24 23:51 ------- The attached patch works, but I'm not clear what other impact it will have. The problem was that SymbolTable.createTypeFromDef assumed that array types would have a content model in which the type of the array could be determined without following <element ref=...> references. That is, it worked fine when the sequence within a complexContent restriction was an <element type=...> (as shown in my sample schema on this bug), but it failed when the type of the sequence was one ref= removed. In this patch, I've changed the behavior of getTypeEntry as follows: when searching for a Type (not Element) entry, first try to find a type with specified qname. if no such type is defined, look for an element with that qname, and return its type. This fixes the reported bug because the problem schema defines an array (complexContent/sequence) whose content model is an <element ref=X> The change described above enables getTypeEntry to find the type of an element with qname X. As I said earlier, I'm unclear what other impact this will have and hope that someone with greater knowledge of the various circumstances in which getTypeEntry is used will give this one a careful review.
