Hi all, The attached is the schema component API proposed by Elena Litani, and reviewed by some of the Xerces developers. Because it's experimental, the interfaces are currently in the package impl.xs.psvi.
Comments are welcome. In particular, we'd appreciate your input on the
following questions.
1. Annotation
An "annotation" contains:
{application information}: A sequence of element information items.
{user information}: A sequence of element information items.
{attributes}: A sequence of attribute information items.
How can we expose *information items*, in what form?
1) DOM nodes: this is easy to implement (because we already parse schema
documents to DOM trees), and it benefits DOM users, but SAX users won't be
able to use it, and we don't want a schema API to have explicit dependency
on DOM.
2) String representation: this doesn't depend on a certain API, but it's
inefficient (we need to serialize DOM nodes to strings), and we also need
to provide namespace declarations, and xml:base, xml:lang attributes that
are defined on ancestor elements.
3) Other suggestions?
2. getName()/getNamespace()
Currently these two methods are on XSObject, and inherited by each
component interface. But some components don't have name/namespace
properties (particle, model group, wildcard, etc.). So should such methods
be on the base interface, or should individual interfaces (where
name/namespace make sense) define them?
We think it depends on what's the typical use of the components:
1) "check names; if names satisfy certain condition, cast, further
operation". If this is the typical use, then the methods should be on
XSObject.
2) "cast; get names; get other properties". In this case, casting happens
anyway, and the methods for names should be on individual interfaces.
What do you think?
3. Actual values
How to expose actual values? Do we want to define interfaces to represent
the actual values (date/time types especially)? After we have such
interfaces, we can return "Object" from related methods.
Currently the methods return a String: the lexical representation of the
value. Again we have a question: should it be any lexical representation,
or normalized, or canonical representation? The canonical one would make
more sense, but:
1) ".0" is appended to integer values (for example, the canonical
representation for integer "1" is "1.0");
2) canonical representation of "base64Binary" is not finalized yet (as far
as I know);
3) do we have support for URI canonicalization?
A related issue to "actual values" is how to expose "equality" and
"ordered" fundamental facets. "Equality" is a fundamental facets that every
value space (hence, every simple type) has, so it makes sense to have a
method on XSSimpleType to check whether two *actual* values are equal. It
also makes sense to compare the order of two *actual* values if the type is
ordered (partially or totally). But both depend on how *actual* values are
represented. We may want to add these two methods when we have interfaces
for actual values.
4. Get global type definitions
One XSModel, you can find these two methods:
public XSNamedMap getComponents(short objectType);
public XSTypeDefinition getTypeDefinition(String name,
String namespace);
The first method *getComponents* takes a parameter indicating the kind of
components, and returns all components of that kind. For type definitions,
we currently have 2 constants: SIMPLE_TYPE and COMPLEX_TYPE, so the user
can either (using *getComponents*) get all simple type definitions, or get
all complex type definitions.
The second method "getTypeDefinition" returns a type definition that
matches the given name/namespace. So this method doesn't care about whether
it's simple or complex type.
This seems to be a bit inconsistent. Two approaches can be adopted to solve
it:
1) Remove *getTypeDefinition* and introduce two methods:
getSimpleTypeDefinition and getComplexTypeDefinition.
2) Remove constants SIMPLE_TYPE and COMPLEX_TYPE, then introduce a new one
TYPE_DEFINITION.
Of course, if approach 2 is taken, a method will be introduced to
TypeDefinition interface to tell whether the type is simple or complex.
>From the schema spec, simple and complex types share the same symbol space,
and "schema" only has one property {type definitions} for both of them, so
approach 2 seems to be more proper, conceptually.
But from certain users, we understand that approach 1 is more preferred,
because it returns what the user really wants.
What do you think?
5. min/max occurrence values
On XSParticle interface, getMin/MaxOccurs returns *int*. Is this enough.
The spec says nonNegtiveInteger (0~+inf). Should we return BigInteger?
Would *long* make it better? (*long* doesn't solve the problem, just it
allows more values than *int*).
Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
(See attached file: psvi.zip)
psvi.zip
Description: Zip archive
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
