[Schema CM API] Partially Implemented!

[sa...@ca.ibm.com]

Hi folks,

I just checked in the implementation of Schema CM API. Please try it out
(if possible). Any comments/feedback/bug-report are welcome.

All interfaces in impl.xs.psvi package except XSAnnotation are implemented.

As I mentioned before, there will be two ways to get at XSModel:
1. From PSVI
2. From preparsed grammars

We don't have full PSVI support yet. I'll be working on that soon. And as I
mentioned in a previous message "[Schema CM API] How it works with grammar
loading", it's not clear yet how to get XSModel from preparsed grammars. So
it seems that this exciting functionality can't be accessed at all.

Well, it is true. :-( But for prototyping purposes, interested users can
use DOMASBuilder to construct ASModel, cast it to ASModelImpl, get grammars
from it, then construct an XSModelImpl from the grammars. Here is some
sample code that shows how this can be done:

import org.apache.xerces.dom3.as.ASModel;
import org.apache.xerces.dom.ASModelImpl;
import org.apache.xerces.impl.xs.psvi.*;
import org.apache.xerces.impl.xs.XSModelImpl;
import org.apache.xerces.impl.xs.SchemaGrammar;
import java.util.Vector;

...

    XSModel as2xsModel(ASModel asmodel) {
        ASModelImpl model = (ASModelImpl)asmodel;
        Vector models = model.getInternalASModels();
        SchemaGrammar[] grammars = new SchemaGrammar[models.size()];
        for (int i = 0; i < models.size(); i++)
            grammars[i] = ((ASModelImpl)models.elementAt(i)).getGrammar();
        return new XSModelImpl(grammars);
    }

Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: [Schema CM API] Partially Implemented!

[Elena Litani <el...@ca.ibm.com>]

Hi Andy, 

Thank you for reviewing the API.

A general comment: the description for most schema components in this
API is isomorphic to the components that they represent, i.e. properties
and their names are as defined in XML Schema PSVI. 

Given some comments we received, for the API to be accepted, it is
crucial that we try to preserve "isomorphism" even if there are some
"derivations of standard method naming". 

Now back to you message..

Andy Clark wrote:
> I'm briefly looking over the API now. The first thing I'm
> noticing is the deviation of standard method naming. For
> example: XSObject#getNamespace instead of getURI 

This should be renamed to getTargetNamespace() given the reasons above.


> XSObjectList#getListLength/getItem instead of getLength/
> item. 

The PSVI API were built in parallel to Abstract Schema API: we tried to
make sure that same object can implement PSVI.XSObjectList and
AS.ASObjectList interfaces, hence those names.
If we decide never to implement Abstract Schemas we can make the change
you request.
 
> Case in point: the interface
> XSAttributeDeclaration has a method called "getTypeDefinition"
> which, in fact, returns an XSSimpleTypeDefinition. But by
> the name, I would have thought that it would return an
> XSTypeDefinition.

The PSVI property is defined as typeDefinition. 
To avoid a cast we decided to return XSSimpleTypeDefinition().
I prefer to keep the name and avoid the cast..

> Also, we're not consistent in the XSConstants interface
> either with choice of naming. Most of the constants have
> a leading prefix (e.g. DERIVATION_*) which others have
> a suffix (e.g. *_DECLARATION) and still others have none
> whatsoever (WILDCARD). 

We tried to use prefixes to allow logical grouping. As for declarations
we did not feel that grouping is important (following the dom.Node
pattern..).
But I don't feel strongly about that.

Thx, 
-- 
Elena Litani / IBM Toronto

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: [Schema CM API] Partially Implemented!

[Andy Clark <an...@apache.org>]

I'm briefly looking over the API now. The first thing I'm
noticing is the deviation of standard method naming. For
example: XSObject#getNamespace instead of getURI and
XSObjectList#getListLength/getItem instead of getLength/
item. XML (and Java) programmers are used to certain
naming conventions in the standard APIs so we should try
to follow suit as much as possible.

And to continue on with naming, there are issues where
methods are poorly formed and don't give the accurate idea
of what they do or return. Case in point: the interface
XSAttributeDeclaration has a method called "getTypeDefinition"
which, in fact, returns an XSSimpleTypeDefinition. But by
the name, I would have thought that it would return an
XSTypeDefinition. 

It can be argued that an attribute's type is always simple 
and there's no need to rename the method. But I prefer to use 
explicit names so that it removes any chance of mis-interpreting 
the behavior. Compare with the XSElementDeclaration#getType-
Definition -- it returns what I would expect from the name, an 
XSTypeDefinition object.

Also, we're not consistent in the XSConstants interface
either with choice of naming. Most of the constants have
a leading prefix (e.g. DERIVATION_*) which others have
a suffix (e.g. *_DECLARATION) and still others have none
whatsoever (WILDCARD). At the very least, we should only
use prefixes. And, unless there's a reason not to, we
should add meaningful prefixes to those constants that
don't have any.

As a side question: should XSConstants have all of the
constants, or just most of them? If we're going to have
commonly shared constants (which by the way adds constant
entries to EVERY class that implements the interface 
instead of just the ONCE in the class/interface where it
applies), why do we have some constants defined elsewhere?
(e.g. XSIDConstraintDefinition)

When I get more time, I'll look over how all of these
interfaces go together.

-- 
Andy Clark * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org