xerces-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Srivastava <Rahul.Srivast...@Sun.COM>
Subject Re: Code for XSDAttributeGroupTraverser
Date Wed, 12 Sep 2001 12:29:45 GMT
Sandy wrote...
> Hi Rahul,

Hi Sandy,

> Thanks for looking into the XSDGroupTraverser and
> XSDAttributeGroupTraverser.

Its my pleasure.

> Though you code basically looks fine to us, there are some points that I
> want to share with you before you proceed.


> 1. How attribute information will be stored in Xerces2 schema grammar.
> As the schema spec states, globally declared attributes result in
> "attribute declaration" in the grammar, while locally declared ones result
> in "attribute use" in the grammar. But in Xerces1, we don't distinguish
> these two concepts. So there were lots of redundant information in Xerces1
> about attribute declaration.


> In Xerces2, we plan to separate these two concepts. (Similar to the
> separation between element declaration and particle.) I'll add a new
> XSAttributeUse class in the v2 branch, which corresponds to the "attribute
> use" concept. And inside each XSAttributeUse instance, there will be a
> reference to an XSAttributeDecl (by index, not object reference).

Well Sandy, in this way you clearly distinguish the attribute declaration from 
attribute usage. On the other hand, even using attributeDeclIndex in lieu of 
XSAttributeUse object would suffice, as, when storing information about an 
element in grammar, you need the set of attributes for this element. So, you can 
use the set of attributeDeclIndices. Why an extra object here?.

Let me be more elaborate. You can have an attribute declared in-line or a 
reference to a globally declared attribute. When you get in-line declaration, 
instantiate XSAttributeDecl, populate it, add to grammar and use this index. If 
you get a reference to a globally declared attribute, check if it exists 
already. If not, its an error, else, use the index of the already existing 
XSAttributeDecl. This will keep things simple and clear.

> 2. How attribute group information will be stored in Xerces2 schema
> grammar.
> An attribute group contains two parts: attribute uses and attribute
> wildcard. I'm thinking of introducing an XSAttributeGroupDecl class to hold
> such information. Do you have any other suggestion, or any opinion on how
> to do it?

Introducing XSAttributeGroupDecl is a really good idea. But, I feel, this object 
should only hold references to attributes/attributeGroups/anyAttribute declared 
inside attributeGroup. So, you can call this an Object of pointers to 
attributes. In element declaration we can give a reference to this object and 
thus the attributes. The sole purpose is to keep these set of attributes grouped 
and use it wherever required.

> 3. What should be returned from the traversal methods of
> XSDAttributeTraverser and XSDAttributeGroupTraverser.
> XSDAttributeTraverser.traverseGlobal: register an XSAttributeDecl, and
> return the index;
> XSDAttributeTraverser.traverseLocal: register an XSAttributeUse, and return
> the index;
> XSDAttributeGroupTraverser.traverseGlobal: register an
> XSAttributeGroupDecl, and return the index;
> XSDAttributeGroupTraverser.traverseLocal: resolve the "ref" attribute to an
> XSAttributeGroupDecl index, and return such index.
> What do you think?

I think it should be:

XSDAttributeTraverser.traverseGlobal: register XSAttributeDecl, return index.
XSDAttributeTraverser.traverseLocal : register XSAttributeDecl, return index
                            resolve "ref" to XSAttributeDecl, return that index.

XSDAttributeGroupTraverser.traverseGlobal: register XSAttributeGroupDecl, retutn 
XSDAttributeGroupTraverser.traverseLocal : resolve "ref" to XSAttributeGroupDecl 
, return that index.

What do you say?.

> 4. What's the responsibility of XSAttributeChecker, and what's the
> responsibility of the traversers.
> As you noticed (and you already did), whenever we traverse an element in
> the schema document, we call XSAttributeChecker.checkAttributes to get the
> attribute values. This method is responsible for checking all attribute
> (and attribute value) errors except one case: it won't report an error if a
> required attribute is missing. The reasons are:
> a. If it's a required attribute, the caller will definitely need it and
> check whether it's present, so we don't need to duplicate the same effort
> in XSAttributeChecker;
> b. In some case, we don't know whether an attribute is required. For
> example, attribute "base" of <restriction> is required when it's in a
> complexType, but optional for a simpleType. So XSAttributeChecker doesn't
> know whether it's an error if "base" is missing.
> No it's clear that the caller (traverse methods) is only responsible for
> reporting errors about missing required attributes. But in your code, you
> also check for attributes that's not allowed for a certain element, which
> is not necessary. (As an example, "name" on local group/attributeGroup)

Well Sandy, I have a clear understanding of XSAttributeChecker.checkAttributes. 
if you have not deleted the mail, in which I attached XSDGroupTraverser.java, 
you will notice that, when checking for global traversal, I have not checked 
local attributes (I mean attributes required for local decl. e.g. "ref") and 
vice-versa. But, when Elena checked in the code to CVS, I found those checks 
were added. Well, adding such checks are not going to harm the functionality but 
they are very well not required. I should have asked Elena about this, but, I 
missed. Therefore, in my next code viz. XSDAttributeGroupTraverser, I did the 

> 5. Some coding habit
> While this is completely up to you, just some thoughts:
> - In Xerces-J, we seldom use '_' in variable names. Andy Clark had an
> outline of coding convention in Xerces-J, which might be helpful to you.
> - In both XSDGroupTraverser and XSDAttributeGroupTraverser classes, both
> traverseLocal and traverseGlobal invoke a common method
> "traverseGroupDecl/traverseAttributeGroupDecl". But there is almost no code
> in common between the global and local cases. Do you have any reason doing
> so? I think we can get rid of the traverse???Decl method, and just put the
> right code into each of the appropriate methods. In fact, Lisa Martin is
> working on removing traverseGroupDecl from the group traverser.

-I have the habit of using the S&G <scope of var.>_<2-3 letter acr. for 
type><Name of var. in Hungarian notation>. Also, I start the opening brace in 
the next line, which I have seldom found. Well, if this is not the convention 
followed here, that's okay. But, this may take a little more time for me to 
code. Anyways, can you tell me exactly where the coding convention is?. I will 
try to use them, onwards.

-You are right. In both my classes, from the traverseLocal and traverseGlobal 
methods, a common method viz. traverseXXXDecl is invoked. Actually, both  
XSDElementTraverser and XSDSimpleTypeTraverser are doing the same thing. In both 
these classes, both the traverseLocal and traverseGlobal methods invoke 
traverseXXX. So, I was provoked by these classes to the same. If you want, I can 
remove these methods for you in my classes. But, I feel dumping the whole code 
again in traverseGlobal or traverseLocal seperately is not a pleasant idea.

> I'm so glad to see you guys actively involving in Xerces2 developing and
> design. And you further code contributions and design opinions are very
> welcome.

Thanks for your suggestions Sandy. If you have more, please put it forward. We 
will be glad.


Sun Microsystems Inc.

To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org

View raw message