I started looking at the code that has been checked into the impl.v2.new_datatypes package and I'm having a few problems with the code. Could someone please explain to me what was fundamentally wrong with the old interfaces that we needed to define completely new ones?
I think that the old set of interfaces are basically sound. So we should start from there as a base and re-examine them to see where they are lacking and if we can clean them up a bit. The biggest problem is defining the *behavior* of the datatype validators when we bring grammar access and grammar caching into the picture. Reviewing what is currently in Xerces2, checked into the impl.v2.datatypes package, we have a datatype validator factory interface for creating datatype instances and we have a datatype validator interface for doing the actual validation of datatype values. By using the factory design pattern, we allow different datatype library implementations to be used interchangeably by the parser. I see this as a good thing. :) The datatype validator factory interface only has a single method to create a datatype validator instance by type name. Other parameters are passed to the factory method such as a base type, a set of facets, and whether or not it is a list type. The datatype validator interface, on the other hand, defines a lot of constants and methods that appear to only be useful for XML Schema. One of my goals is that the datatype validator implementation will be general enough that it can support the union of all of the data- types available in DTD and XML Schema grammars. Some methods have creapt into the interface since it was first designed. So I'd like someone knowledgable about it to tell me why they were added. For instance: getWSFacet, getFinalSet, and setFinalSet. I realize that the method getBaseValidator was added so that you could call these other methods on the base type but why were the methods added in the first place? I'll be posting a series of message about this topic in the upcoming days to try to arrive at a good set of interfaces. I would love to get everyone's opinions as we go through the process. -- Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
