hi neil,
> we now have only an XSDocumentInfo object to store the info specific to
> a given schema document. The hard part about schema traversing is not
> marching through the children of the schema document's root node--which is
> all a schemaTraverser class could really doo--;
I can understand how u are thinking, my point was, it would be nice if we could
separate out functionality as much as possible from a class which it is not
intended to do.
That's what we try to do most of times, adding abstraction layer.
> what's hard is to keep the
> namespace bindings in sync, manage requests from traversers, keep track of
> what's already been done, make sure <redefine>s don't blow up, etc...
Agreed , these are hard to do and truly speaking, hard for me to visualize
*certain* things , (i have many...) like how we are actually going to use
fDependencyMap instance of Hashtable where we store XSDocumentInfo and
dependecies. Any insight will be helpful.
For instance, there's still
> lots of thought to be done on just how schema validation should look given
> that we need to abandon the universal validator from Xerces 1. Does this
> sort of thing interest you at all?
YES, it interests me and i know it would be good food for brain ! Have u
given any thoughts about designing SchemaValidator and issues u have come across
? It would be good if u post something on that. Sandy has posted some
interesting things. Thanks.
reagards
Neeraj Bajaj
---------------------
Sun Microsystems, inc.
Ph.91-80-2298989 x87425.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
