Wednesday, August 19, 2009

Exploring xsd.core

I mentioned in the previous blog that the getProperty() method under the class XSDSchemaAdapter in org.eclipse.wst.xsd.core, calculates the name space of an attribute. However, as i looked more into the code, I found that the getProperty() method does not do more than retrieving the value from a created attribute. So, to find out how the name space of an attribute is calculated, I would need to look into the code where an attribute is created.

First, I go back to org.eclipse.wst.xml.core, and find out the method creating an element, which is visitCMElementDeclaration(). In visitCMElementDeclaration(), the following line of code is trying to creat the attributes of an element.

CMNamedNodeMap nodeMap = ed.getAttributes();

When ed is passed to visitCMElementDeclaration(), it is claimed to be an instance of CMElementDeclaration, but it is actually of data type XSDElementDeclarationAdapter derived from ElementDeclarationBaseImpl. XSDElementDeclarationAdapter and ElementDeclarationBaseImpl are both defined in org.eclipse.wst.xsd.core, is one of the methods defined in ElementDeclarationBaseImpl. The following lines of code in getAttributes() are creating the attributes of an element.

XSDComplexTypeDefinition ctd = (XSDComplexTypeDefinition) xsdTypeDefinition;
for (Iterator i = ctd.getAttributeUses().iterator(); i.hasNext();) {    XSDAttributeUse xsdAttributeUse = (XSDAttributeUse);
    XSDAttributeUseAdapter adapter =          (XSDAttributeUseAdapter)getAdapter(xsdAttributeUse);
    if (adapter != null && adapter.getNodeName() != null) {
       map.getHashtable().put(adapter.getNodeName(), adapter);

The most important variable in the these lines is ctd, which is corresponding to the definition of an element. XSDComplexTypeDefinition is defined in org.eclipse.xsd_2.5.0.v200905041408.jar in the plug-in dependencies folder. At this point, the "lang" attribute still gets the correct name space url, which is However, once the CMNode, representing the "lang" attribute, is converted to CMDocument later in, the namespace url, for some unknown reason, has been changed to, which I think is the cause of Bug 245698

Tuesday, August 18, 2009

Move from xml.core to xsd.core

In the past few weeks, I have looked into org.eclipse.wst.xsd.core, and find the following line of code in calculating the name space of an element/attribute.

String qualification = (String)cmNode.getProperty("http://org.eclipse.wst/cm/properties/nsPrefixQualification");

The computerName() method from which I got the above line of code is called from the following line of code in, visitCMAttributeDeclaration().

String value = valueHelper.getValue(ad, namespaceTable);

ad is an instance of CMAttributeDeclaration, but it is really with the data type of XSDAttrubuteUseAdapter defined in org.eclipse.wst.xsd.core, However, as it is shown in the line of code calculating the name space of an element/attribute, any CMNode object(in this case it is ad) is converted to a CMDocument first before the getProperty() method is invoked in, computeName().

As a result of that, the getProperty() method invoked is the one under XSDSchemaAdapter class in, and the following lines of code are calculating the name space of element/attribute by calling getTargetNamespace().

     result = xsdSchema.getTargetNamespace();

xsdSchema is an instance of org.eclipse.xsd.XSDSchema, which is defined in org.eclipse.xsd_2.5.0.v200905041408.jar in the plug-in dependencies folder.

Monday, August 3, 2009

More Code Inspection for Bug 245698

As I have mentioned I the previous post, the variable, contentBuilder which is an instance of DOMContentBuilderImpl, is handler the work of creating an XML document in createXMLDocument method of Specifically, the following line in createXMLDocument is trying to create an XML document:

contentBuilder.createDefaultRootContent(cmDocument, cmElementDeclaration, namespaceInfoList);

To get more detail about createDefaultRootContent, I checked out the code for, which is under org.eclipse.wst.xml.core >> src-contentmodel >> org.eclipse.wst.xml.core.internal.contentmodel.util.

When I looked into createDefaultRootContent in, I found out createDefaultRootContent is only creating the root element of an XML document, the method that actually create the other elements in an XML file is createDefaultContent. There are only three lines of code in createDefaultContent. The line dealing with creating XML document elements is:


So then, I looked into the function with the following signature in

public void visitCMElementDeclaration(CMElementDeclaration ed)

Within visitCMElementDeclaration, I found the following lines responsible for creating attributes within an element.

for (int j = 0; j < size; j++) {
} does not have any definition for visitCMNode(), but DOMContentBuilderImpl extends from CMVisitor. So, I checked out the code for, which is in the same package as, and I found the definition for visitCMNode(). When I looked into the code for visitCMNode() in, I found that this method is doing more than creating attributes for an XML element, but when it is used to create attributes for an element, another method, visitCMAttributeDeclaration(), is called from visitCMNode(). In, I found that visitCMAttributeDeclaration() is declared, but not defined. So, I had to go back to to find out the definition for visitCMAttributeDeclaration(). Then I found the following line in visitCMAttributeDeclaration().

String name = computeName(ad, currentParent);

In this line of code, computeName() is the method used to calculated the qualified name of an attribute. So then, I move to the definition for computeName() in There, computeName() in DOMNamespaceHelper is called to calculate the prefix of an attribute. Within computeName(), the following line is used to get the prefix of an attribute.

String qualification = (String)cmNode.getProperty("http://org.eclipse.wst/cm/properties/nsPrefixQualification");

In my old post "Cause of Bug245698", I have explained that the reason why the XML validator detects the error in the newly created XML document is the attribute has an wrong prefix. So to fix this bug, I have to look into the above line calculating the prefix of an attribute and figure out how the prefix is calculated.