Advanced View Design Specification

Author: Ajit Bhate


This document describes the design and implementation of the schema advanced view aka columns view. We will consider the actual UI and allowed actions. Since we already have an implementation for most of this part in TPR2, this document will start from the implementation and provide extensions and improvements to it. The main areas that will be covered are multifile support, multilevel categorization, and various actions like creation of new types and advanced customizers.


As of TPR2 we have a base implementation of advanced view aka columns view. The Schema UI Basic module provides this implementation. We can say that this implementation is broadly divided into following

Schema component nodes infrastructure:

It uses the Netbeans Nodes infrastructure. The UI shows schema structure in two representations. First is the structural view which can be seen under the All Components node (child of schema node). This presents the schema components in their physical order in the file. Another view is the categorized view, which presents the schema components in logical groupings or categories. The implementation is such that it allows lazy creation of children whenever required. The node factory implementation allows that. It is possible create own implementation of node factory to satisfy specific UI needs.

Columns view UI:

The UI is a multiple column representation. When a user selects a schema component node in an column a new column is appended with the selected component as the root. Columns are added or removed appropriately, depending on further selections.

Supported Actions:

Currently a few actions are supported on the advanced view UI, which include Remove, Go To Source, Show Usages and Add (new types). Remove action removes a component if it is not referenced anywhere in current schema. Go To Source action shows source view with caret position at the start of selected component. Show Usages will take to the Analysis view. The Add allows addition of schema components from the sub menu to selected schema component if allowed.


  • We need to support multifile view. That is if a schema has includes and/or imports and/or redefines of other schemas, we need a way to show inherited components.

  • We need to refine some of the categories to distinguish external references.

  • We need to allow groupings by namespaces and file locations.

  • We need a way to show primitive types.

  • Addition of all components must be supported. The algorithm must be intelligent enough to enable/disable (visible/invisible) the submenu items based upon current selection.

  • Advanced customizers must be provided to modify an existing component.

  • Other actions like cut/copy/paste and drag/drop must be supported.

  • Current implementation does not satisfy above requirements fully. So we propose some improvements to current implementation which are described in section below


Multifile support

We propose that we will create separate categories for imports, includes and redefine under the external references node under schema node. Each import/include/redefine will have a separate node which will be sub-tree representing corresponding schema. In addition we will have 3 special nodes, All inherited components, which will show categorized list of inherited components from all the included, imported and redefined schemas, By Namespaces, which further categorize these based on their namespaces, and finally By File Location which further categorize these based on their file location.

We propose that we will also show all the primitive types under primitive types node under external references.

So the new UI will look like

Schema A

External References


Schema B





Schema C






All Inherited Components

Inherited GCT...

Inherited GE...

Inherited Components By Namespaces


Inherited GCT...

Inherited GE...


Inherited GCT...

Inherited GE...

Inherited Components By File Locations

File Location 1

Inherited GCT...

Inherited GE...

File Location 2

Inherited GCT...

Inherited GE...

Primitive Types




There are some open issues which are described in open issues section.

Addition of new types

Current implementation supports addition of elements, complex types, attributes, attribute groups, all, sequence and choice. We will need to support addition of all schema components including annotations simple types, groups, notations, union etc. Also depending upon current selection we need to enable/disable the types which can be created under it. We use Netbeans new types framework, we will have to make the getNewTypes intelligent enough to return new types based on current component structure. There are special considerations in some cases that we need to support. For example an element does not allow addition of an element directly but its content model does. So in such cases we need to support additions of such types even if they are indirect. See the Schema UI Specification” for detailed information on new types.

Advanced customizers for schema components

Current implementation allows creation of many new components. However after a component is created, we do not have a good story about modifying it. It is possible to change some aspects using the property pane or yes using the text view. But its not user friendly and does not give collective way of modification. We propose that we reuse the new component wizards to some extent to allow modification of existing components and addition of more wizard customizers if necessary. We will add an action say Customize in the context menu.

Other actions like cut/copy/paste, search, drag and drop will be addressed in separate specifications.

Open issues


  • How many levels do we allow user to drill down for external references? Minimum would be to show only the global components and do not allow their expansion and maximum would be allowing complete expansion. We might add an action in context menu for the node representing external reference to open the file in different multi-view.

  • Should there be the ability to view the inherited components under the top level global components such as GlobalComplexType?

  • How do we handle modifications/readonlyness of external references?

  • Do we allow go to source for externally referenced components? If yes what happens?

  • We use columns view for reference type of properties. What changes do we need to continue that support?

Primitive Types

  • Should we also show the primitive types under the schema namespace ?

  • When using primitive types it would be really useful to include some help to describe the differences between the primitive types, with examples.

New Types and customizers

  • Is it better to add intelligence to getNewTypes method in schema component nodes? Or can we have a canCreate method in NewTypes which will allow enable/disable of that type depending upon the current context?

  • Should the customizers present data about included facets and/or content models?


  • What should be the behavior when we delete?

  • How do we handle enumerations and patterns?

Nice to have

  • Should annotation support be first class (combined editing with the element), as in XML spy? Annotations are typed directly.

  • Should we provide a instance view node where the reverse engineering would show what an instance document would look like (outline). This could be done on elements and types.

  • Should we have the ability to perform a pattern slice on the schema? Perhaps we could have a pattern view to classify patterns being used.

  • Category icons revisit. Use different icons for open close?

Project Features

About this Project

XML was started in November 2009, is owned by dstrupl, and has 62 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm