Hi Neeraj,
Not sure whether you were following the list a month or so ago, but I
posted a couple of messages back then devoted to how the schema parsing
design could look. XSDHandler came pretty much directly from these
e-mails; I never did get much feedback. :-(
Anyway, without explaining everything again,
>It seems primary job of XSDHandler is to co-ordinate the construction of a
grammar object corresponding to a schema.
True, but since we have one grammar for every namespace, if the schema
under consideration imports some other schema, it will be necessary for
XSDHandler to construct more than one grammar object.
>I will suggest making one more class ,say, "SchemaTraverser"
for the purpose of what has been done in functions like
>constructTrees(), traverseSchema() of XSDHandler.
Note that should be traverseSchemas(). And the 's'es on this and
constructTrees(...) are not accidental: it's precisely because it's so
common to reference components beyond a particular schema document that we
gave up on the Xerces1 strategy of being schema-document-centric. That's
why 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--; 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...
>Also a class which is dealing with Grammar, it need not to interact with
all types of traversers.
You won't like this, but it turns out that the traversers themselves
unavoidably often need access to grammar objects, so that they can put the
results of their efforts somewhere. We tried hard to avoid this, but
couldn't find a way to do so.
It's also true that the traversers have to deal with the handler unless
they want to take on the job of figuring out where the components they need
are defined...
>but if anybody there likes this idea ,i am ready to spend some time on it.
Well even though I'm not too excited about this idea, there sure are lots
of places that need work on this side of X2! 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?
Cheers,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
