This provides an API for the XML Schema Standard Part 1 and Part 2; for differences between the current version of the API and the previous version of the API, please see the Appendix.
The abstract XML Schema Components, as described in Part 1 of the Standard, are related according to this hierarchy:
In this UML notation, each feature (i.e., each relation or attribute) Xyz in a diagram, corresponds to a getXyz method in Java for accessing that feature. If the feature is many-valued, the getXyz method yields a list, which can be modified directly using standard Java List API; otherwise a corresponding setXyz method is available for modification. A relation with a black diamond corresponds to a containment relation; these form the basis for the concrete tree structure of the model. A relation with a white diamond corresponds to a shared psuedo-containment relation; it is used only for documentation purposes since it is not logically different from a relation with no diamond. In general, the white diamond relations represent relations defined directly in the XML Schema specification. They are typically computed from other relations and hence should not be modified directly. The exception to this rule are relations involving types, e.g., base-type, member-type, item-type, and element- or attribute-type.
Throughout this Javadoc, the distinction between methods that support the abstract features representing concepts defined in the XML Schema specification verses methods that support the concrete features representing the syntactic structure of the XML serialization, will be carefully emphasized. The former support read-only analysis whereas the later support editing.
The abstract XML Schema Components have the following defined relations:
This is very similar to the standard non-normative Schema Components Diagram.
The abstract XML Schema Components have the following defined attributes:
The abstract XML Schema Components, as described in Part 2 of the Standard, are related according to this hierarchy with these defined relations and attributes:
The abstract XML Schema Components, as described in Part 1 and Part 2 of the Standard, are annotated as follows:
The set of abstract XML Schema Components is extended to represent the concrete syntax as follows:
The concrete attributes are represented as follows:
The concrete containment relations are represented as follows:
The following concrete components resolve to abstract components:
The following diagnostics are produced by validation:
The following concrete components have supplemental relations and attributes:
An earlier version of this API was incorporated into Websphere Studio Workbench v2.0 beta,
in which the package names were called com.ibm.etools.xsd
.
This older version of the API was generated using more complex rules than this current version. As a result, the newer version has significantly fewer (redundant) methods.
All methods of the form:
Boolean getXyz() void setXyz(Boolean)are removed. Use this form instead:
boolean isXyz(); void setXyz(boolean);
All methods of the form:
Integer getXyz(); void setXyz(Integer); int getXyzValue();are removed. Use this form instead:
int getXyz(int); void setXyz(int);
All methods of the form
Abc isSetXyz()where
getXyz() != nullyields the same answer, have been removed. Use a null test instead.
Enumerations are now implemented using Java type-safe enums, rather than using EEnumLiteral. As a result, this set of methods:
Integer getXyz(); String getXyzString(); int getXyzValue(); EEnumLiteral getXyzLiteral(); void setXyz(Integer); void setXyz(String); void setXyz(int); void setXyz(EEnumLiteral);is reduced to
Abc getXyz(); void setXyz(Abc);where Abc is the type-same enumeration. Rather than accessing the literal like this:
EEnumLiteral XSDPackage.getAbc__EnumeratorGhi();you can access the literal like this:
Abc.ENUMERATOR_GHI_LITERALThe name and int value are accessible like this:
Abc.ENUMERATOR_GHI_LITERAL.getName() Abc.ENUMERATOR_GHI_LITERAL.getValue()And conversion from String or int is supported like this:
Abc.get(Abc.ENUMERATOR_GHI_LITERAL.getName()) Abc.get(Abc.ENUMERATOR_GHI_LITERAL.getValue())
Naturally there have been many changes within EMF itself. Below are described the most significant changes that will impact the XSD client.
Rather than accessing a package or factory like this:
XSDPackage xsdPackage = (XSDPackage)RefRegister.getPackage(XSDPackage.packageURI); XSDFactory xsdFactory = xsdPackage.getXSDFactory();you can access it like this:
XSDPackage.eINSTANCE; XSDFactory.eINSTANCE;
Rather than registering the resource factory like this:
ResourceFactoryRegister.registerExtension("xsd", new XSDResourceFactoryImpl());you can register it like this:
Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("xsd", new XSDResourceFactoryImpl());You can also do this directly on just a resource set now too:
ResourceSet resourceSet = new ResourceSetImpl(); resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xsd", new XSDResourceFactoryImpl());A resource is loaded like this:
XSDResourceImpl xsdSchemaResource = (XSDResourceImpl)resourceSet.getResource(URI.createDeviceURI(xsdSchemaURI), true);
The URIReference for XSDComponet and XSDDiagnostic have been removed. The function is subsumbed by the EMF concept of a URI Fragment Path.
The concept of ownership has been eliminated in favor of "transient" containment. This ensures that absolutely every valid component is contained by a schema. The relations XSDConcreteComponent.getDiagnostics(), XSDSimpleTypeDefinition.getFundamentalFacets(), and XSDSchema.getIncorporatedVersions(), are now black diamond, and XSDDiagnostic extends XSDConcreteComponent. The new relations XSDSimpleTypeDefinition.getSyntheticFacets(), XSDComplexTypeDefinition.getSyntheticParticle(), XSDAttributeGroupDefinition.getSyntheticWildcard(), and XSDComplexTypeDefiniton.getSyntheticWildcard() are defined to contain the synthesized components that were formerly only just owned. None of these relations should be modified by the client.
First version, August 1, 2002, donated by IBM Corporation.