XML Schema Refactoring Tools XML Schema Refactoring Tools

Home > Products > Liquid XML Studio > XML Schema Refactoring Tools

The XML Schema Refactoring menu provides automated tools for making global changes to your element and attribute definitions across multiple XSDs.

This can be extremely useful when working with XML Schema containing <include> or <import> to other XSDs, and especially when you have generated an XSD using XML source data with the inferring tools.

Rather than having to edit your XSDs manually, the Refactoring menu provides automated tools for making global changes to your element and attribute definitions. Such amendments can alter the way in which the structural definitions within your XSDs are organized, making them accessible for reuse.

Accessing Refactoring Options

With an XSD open in Liquid XML Studio, you can access the Refactoring menu simply by right-clicking an entity in the design view. The refactoring options are contextual, so you will only see options that are appropriate to the entity you have selected. The options include:

  • Rename
  • Convert to Global Type
  • Convert to Global Element
  • Convert to Global Attribute

Renaming

With an XSD open in the editor, you can select the Rename option in the Refactoring menu to rename entities in it at any time. The Rename option is available for root elements and attributes, groups and attribute groups, complex and simple types. On selecting Rename, you will be presented with a prompt in which to enter the new name.

If you are working with multiple XSD documents, with references to the entity you are renaming in these other documents, they will be altered when you carry out the renaming process. When you enter your new name and click OK, you will be presented with an overview of any such knock-on effects, so that you understand the consequences of the operation before going ahead with it. If any other documents are affected by the renaming, they will be opened in Liquid XML Studio immediately in case you need to check or carry out further amendments on them.

It's worth being aware that deciding to undo the renaming operation can be troublesome in cases where multiple XSDs are involved. If this happens, make sure you undo the renaming in each affected file.

Converting to Global Type

You can use the Refactoring menu to convert items in your XML Schema to global types. This option is available for restricted simple type attributes, restricted simple type elements and restricted extended or restricted complex type elements. The root element created on carrying out this refactoring operation will be a simple or complex type child of the schema. When Liquid XML Studio creates the new root type, it will replace the original entity with a reference to the newly added type.

The three conversion refactoring options alter the fundamental structure of your XSD, since they each add a new root entity. The changes resulting from these three operations therefore affect the document at a root level as well as the original location of the entity you have carried out the refactoring operation on.

Converting to Global Element

The Refactoring menu provides an option to convert an entity in your XSD to a global element. On selecting this option the item in question will be moved to the schema root, defined as an element there and referenced from its original location prior to refactoring. Like the other refactoring tools, this can aid code reuse in large or complex projects.

Converting to Global Attribute

As with the global element conversion operation, you can convert attributes to global attributes using the refactoring tools in the XSD editor. When you carry out this process, your original attribute is replaced with a reference to a new attribute defined at a global level, i.e. as a root entity within the schema. Again, this allows you to potentially reuse the attribute within your project either in the current XSD or in other linked schema files.

An Example

Now we've run through the options within the Refactoring menu, let's work through a simple example. Consider the following XSD code, inferred from sample XML data:

<xs:schema xmlns:lt="http://liquid-technologies.com"
        attributeFormDefault="unqualified"
        elementFormDefault="qualified"
        targetNamespace="http://liquid-technologies.com"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="clients">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" name="department">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" maxOccurs="unbounded" name="customer">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element minOccurs="0" name="cust_name" type="xs:string" />
                    <xs:element minOccurs="0" name="cust_ref" type="xs:string" />
                    <xs:element minOccurs="0" name="cust_since" type="xs:date" />
                  </xs:sequence>
                  <xs:attribute name="account" type="xs:string" use="optional" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute name="division" type="xs:string" use="optional" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Here is the design view presenting a visual representation of the XSD structure as it appears initially:

If we first carry out the renaming operation within this schema, changing the clients element to business_clients the XSD will be amended as follows:

<xs:schema xmlns:lt="http://liquid-technologies.com"
        attributeFormDefault="unqualified"
        elementFormDefault="qualified"
        targetNamespace="http://liquid-technologies.com"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="business_clients">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" name="department">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" maxOccurs="unbounded" name="customer">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element minOccurs="0" name="cust_name" type="xs:string" />
                    <xs:element minOccurs="0" name="cust_ref" type="xs:string" />
                    <xs:element minOccurs="0" name="cust_since" type="xs:date" />
                  </xs:sequence>
                  <xs:attribute name="account" type="xs:string" use="optional" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute name="division" type="xs:string" use="optional" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Next let's refactor an attribute, converting division to a global attribute. The code updates as follows:

<xs:schema xmlns:lt="http://liquid-technologies.com"
        attributeFormDefault="unqualified"
        elementFormDefault="qualified"
        targetNamespace="http://liquid-technologies.com"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="business_clients">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" name="department">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" maxOccurs="unbounded" name="customer">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element minOccurs="0" name="cust_name" type="xs:string" />
                    <xs:element minOccurs="0" name="cust_ref" type="xs:string" />
                    <xs:element minOccurs="0" name="cust_since" type="xs:date" />
                  </xs:sequence>
                  <xs:attribute name="account" type="xs:string" use="optional" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute ref="lt:division" use="optional" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:attribute name="division" type="xs:string" />
</xs:schema>

As you can see division is now defined as a global attribute, with its original listing in the schema structure now represented as a reference. Notice the use of the namespace prefix, matching the target namespace listed within the schema element in which the attribute is defined, now globally. Now if we refactor again, this time carrying out two operations. We will convert the cust_name element to a global element and the customer element to a global type, choosing customerType as the type name when prompted:

<xs:schema xmlns:lt="http://liquid-technologies.com"
        attributeFormDefault="unqualified"
        elementFormDefault="qualified"
        targetNamespace="http://liquid-technologies.com"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="business_clients">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" name="department">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" maxOccurs="unbounded" name="customer">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="customer" type="lt:customerType" minOccurs="0" maxOccurs="unbounded" />
                  </xs:sequence>
                  <xs:attribute name="account" type="xs:string" use="optional" />
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute ref="lt:division" use="optional" />
            <xs:element name="cust_name" type="xs:string" />
            <xs:complexType name="customerType">
              <xs:sequence>
                <xs:element ref="lt:cust_name" minOccurs="0" />
                <xs:element name="cust_ref" type="xs:string" minOccurs="0" />
                <xs:element name="cust_since" type="xs:date" minOccurs="0" />
              </xs:sequence>
              <xs:attribute name="account" type="xs:string" use="optional" />
            </xs:complexType>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:attribute name="division" type="xs:string" />
</xs:schema>

Whenever you edit an XSD, you may wish to consider generating sample XML data from it, since this often gives a clearer indication of whether or not the structures meet your project needs.

Conclusion

As we have explored above, the refactoring tools in Liquid XML Studio automate common refactoring processes. As with the XSD utilities in general within the Studio, the refactoring options let you strike a balance between automation and control over the details of your schema structures. If you infer XML Schema from source XML regularly, you will know that some level of editing is often required following such processes. With the Refactoring menu you can reduce or even eliminate the number of manual code changes you need to make to your inferred schemas.

Once you have your XML Schema structures designed in a way that suits your needs, you can get on and focus on the unique aspects of your projects. If you do carry out refactoring processes, do take the time to check that any side effects of the changes on linked XSDs allow them to remain consistent with associated processing components such as client applications.

Video Tutorials

VIEW TUTORIAL XML Schema Editor Overview

XML Schema Editor Overview

This video overview shows how to work in the graphical, text and split views, adding items, changing properties and updating documentation annotations.

VIEW TUTORIAL Generate a Sample XML Document

Generate a Sample XML Document

This video tutorial shows you how to create a sample XML document from an industry standard schema (Google Site Map).

VIEW TUTORIAL Generate HTML Documentation

Generate HTML Documentation

This video tutorial shows how to create HTML documentation for an XML Schema.

VIEW TUTORIAL XML Data Binder

XML Data Binding

This video tutorial shows you how to generate strongly typed API source code from your XSD using the Liquid XML Data Binder.

VIEW TUTORIAL XML Data Mapper

XML Data Mapper

This video tutorial shows how to create a mapping transform, using the graphical drag and drop interface, to convert XML data of different XML Schema.

Like what you see? Try Liquid XML Free Free Trial

More XML Tools

FEATURE DETAILS

Graphical XML Schema Editor

Visualize and edit an abstracted view of your XML schema (XSD) using an intuitive user interface, and validate your XSD against the W3C standards. Includes split graphical and text views, intellisense, syntax highlighting, drag and drop, copy and paste, and multi-step undo/redo.

FEATURE DETAILS Graphical WSDL Editor

Graphical WSDL Editor

Visualize and edit an abstracted view of your Web Service using an intuitive user interface, and validate your WSDL against the W3C standards. Includes split graphical and text views, intellisense, syntax highlighting, drag and drop, copy and paste, and multi-step undo/redo.

FEATURE DETAILS XSLT Editor and Debugger

XSLT Editor and Debugger

Author, validate and debug your XSLT style sheet, set breakpoints within the XSLT source, watch variables and analyse the call stack. Includes intellisense, syntax highlighting, drag and drop, copy and paste, and multi-step undo/redo.

FEATURE DETAILS XQuery Editor and Debugger

XQuery Editor and Debugger

Author, validate and debug your XQuery module or library, set breakpoints within the XSLT source, watch variables and analyse the call stack. Includes intellisense, syntax highlighting, drag and drop, copy and paste, and multi-step undo/redo.