> Sandy wrote... > > XSAttributeGroupDecl: > > It's not yet decided how to handle duplicate attribute uses: whether in the > traverser, or in the decl. And depending on the situation, some duplicated > attribute uses indicate an error, while others don't. Lisa's working on > this aspect. She might get back to you later.
Fine. I will get in touch with Lisa. > SubstitutionGroupHandler: > > 1. getSubstitutionGroup(): > > According to the spec, the definition of a substitution group > (http://www.w3.org/TR/xmlschema-1/#cos-equiv-class), there are 3 aspects > that you need to modify for this method: > > a. Include the element itself in the returned set; > b. Transitively find other elements. For example, A substitutes B, and B > substitutes C, then both A and B are in the substitution group of C; > c. Since all element/attribute names and namespaces are added into the same > symbol table, you should use == to compare two strings, instead of > String.equals(). Done. XSGrammarResolver is back, as the element itself is to be fetched from grammar. > In the Grammar class of Xerces1, there was code for getting the > substitution group of a given element. You can refer to that if you like. > > 2. checkSubstitutionGroupOK() > > a. You don't need to access the XSDocumentInfo. The default block value is > already reflected in XSElementDecl.fBlock, if "block" attribute is not > specified on the element declaration. Actually, when I was coding SubstitutionGroupHandler, element traverser was getting element's block attr. as: element.fBlock = blockAtt == null ? SchemaSymbols.EMPTY_SET : blockAtt.shortValue(); I was to point this, but it slipped. I can see now, that element and other traversers has been modified to incorporate xxDefault attributes. Cool!. > b. The spec requires to check whether the type of "element" is validly > derived from that of "element.fSubGroup". Such checking is not as simple as > type1.base == type2. As you can see from "Type derivation OK > (simple/complex)", the checking is quite complicated. I've implemented such > derivation checking in XSConstraints. You can simply call > "checkTypeDerivationOk()". Ya, I saw XSConstraints. This will really simplify things. > In fact, since "checkTypeDerivationOk()" is already implemented, we don't > need to this "checkSubstitutionGroupOk()" method, because it's content > would simply be a call to "checktypeDerivationOk()". I'll modify > ElementTraverser to call "checktypeDerivationOk()" directly. As of now, element traverser is not making any check for substitution allowed. It only sees, if there is a substitutionGroup attribute declared, then get the element pointed and store in element.fSubGroup. If E1 substitutes E2, then, 1.) E2 should not block substitution 2.) E1's type should be same or derived from E2's type. So, if you directly call checkDerivationOk(), this means you shift point 1.) check in traverser. Though there is not much code in this method, still, I feel you should not remove this method, as it performs the check for substitution allowed/not at one place, which looks reasonable. Also, with all these three methods viz. add, get, check, the class SubstitutionGroupHandler looks complete. I would suggest adding one more method to this class, by overloading getSubstitutionGroup as: XSElementDecl[] getSubstitutionGroup(XSElementDecl); Please find attached code for SubstitutionGroupHandler. Cheers, Rahul. Sun Microsystems, Inc.
SubstitutionGroupHandler.java
Description: SubstitutionGroupHandler.java
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
