I am going thru these apis? I will send my feedbacks shortly. Are they based on w3c CM (component model) API spec proposed in april 2001? Its http://lists.w3.org/Archives/Member/w3c-archive/2001Apr/att-0138/01-xml-schema-cm-api.html.
There is one recent proposal at w3c, i think its not yet accepted. However there is some discussion in the w3c WG about working on PSVI apis. This proposal is at: http://www.w3.org/2002/04/xmlschema-psvi-in-xml.html, though it does not define APIs. cheers, -vivek. [EMAIL PROTECTED] wrote: > > Right after I posted the previous message, I realized that there are so > many name conflicts between the interface names and the class names already > in impl.xs package. > > To avoid writing the full package name (org.apache.xerces.impl.xs.psvi) all > over the files, I've changed some of the interface names from XXXDecl to > XXXDeclaration. > > The updated files are attached. I'm also cc'ing the user list, in case > people there are interested. > > Thanks, > Sandy Gao > Software Developer, IBM Canada > (1-905) 413-3255 > [EMAIL PROTECTED] > > (See attached file: psvi.zip) > > > Sandy > Gao/Toronto/IB To: [EMAIL PROTECTED] > M@IBMCA cc: > Subject: [Xerces2] Please review: >schema component API > 05/03/2002 > 12:16 PM > Please respond > to > xerces-j-dev > > > > 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] > > ------------------------------------------------------------------------ > Name: psvi.zip > psvi.zip Type: Zip Compressed Data (application/x-zip-compressed) > Encoding: base64 > > ------------------------------------------------------------------------ > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
