Re: [Xerces2]: status of the v1 schema port and packaging issues

[ne...@ca.ibm.com]

Hi Andy,

> Really? I've been busy on other projects lately and didn't
know you were making such great progress! :) Once we clean
up the packaging, should we do another beta release with
preliminary Schema support?

That's certainly a thought, so long as we're ready for the onslaught of
bogus bug reports...

>I might be good to put it on a branch regardless.

Did you mean "It" here, or were you volunteering?  :-)

>> - port/move the v1.util.regex package to util.regex

>I don't know about this one. I would like to keep the
code modular which means that we should try to keep the
packages separate. Since the regular expression code is
only needed for Schema validation, I think that it should
be under the impl.schema package.

Fair enough.

>> - modify xni.parsers.XMLEntityResolver and impl.validation.GrammarPool
> and/or add some new XNI classes to reflect the Grammar caching discussion

>I don't like this one. I would like to keep XNI as only
the streaming infoset and parser construction pieces.

But you've already got an XMLEntityResolver in the xni.parsers directory.
If we want this class to be optimally useful, then it makes sense to change
it so that it's good for more than DTD location, IMHO.  This would seem to
involve passing some kind of LocationHint interface to its ResolveEntity
method, as Sandy/Petr/Curt were discussing.

> Validation is not inherently something needed in either
of these two pieces, so it shouldn't be included.

Validation is already contemplated in the pipeline and we've got to provide
some standardized, general way for validators to find their food.

> And I have serious reservations about trying to define
grammar information for inclusion in XNI. The reason is
that I don't think any single grammar model can adequately
capture all sets of XML grammars.

I think it would be useful to have some kind of really general (empty?)
Grammar interface simply so that GrammarPools (or GrammarResolvers or
whatever we call them) have something other than Object to return.  But I
agree with you that we can have very little detail here.

>> - find a sensible home for v2.SAXParser, v2.SchemaParser,
> v2.SchemaParserConfiguration

>Well, if things are really going as well as you say, I think
that we won't need this because we can put the Schema
validator into the standard parser configuration used by
both the DOM and SAX parsers.

Wouldn't we rather have a StandardSchemaParserConfiguration extending
StandardParserConfiguration or something like that?  Just a thought.

Cheers,
Neil


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

Re: [Xerces2]: status of the v1 schema port and packaging issues

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

neilg@ca.ibm.com wrote:
> That's certainly a thought, so long as we're ready for the 
> onslaught of bogus bug reports...

So do you have an updated forecast regarding when you
think you'll be done? or close enough to warrant a new
beta release?

> >> - modify xni.parsers.XMLEntityResolver and impl.validation.GrammarPool
> >> and/or add some new XNI classes to reflect the Grammar caching discussion
> 
> >I don't like this one. I would like to keep XNI as only
> >the streaming infoset and parser construction pieces.
> 
> But you've already got an XMLEntityResolver in the xni.parsers directory.
> If we want this class to be optimally useful, then it makes sense to change
> it so that it's good for more than DTD location, IMHO.  This would seem to
> involve passing some kind of LocationHint interface to its ResolveEntity
> method, as Sandy/Petr/Curt were discussing.

What threads were these discussions in? I can't seem
to find them now. Until I can review the discussion,
I'm still not convinced that the XMLEntityResolver
needs to be modified.

> Validation is already contemplated in the pipeline and we've got to provide
> some standardized, general way for validators to find their food.

We have a generic mechanism for that -- we don't need
to modify XNI to provide an additional mechanism for
something that is implementation dependent.

> I think it would be useful to have some kind of really general (empty?)
> Grammar interface simply so that GrammarPools (or GrammarResolvers or
> whatever we call them) have something other than Object to return.  But I

But that doesn't need to be in XNI for it to be defined 
and used by the Xerces2 reference implementation.

> Wouldn't we rather have a StandardSchemaParserConfiguration extending
> StandardParserConfiguration or something like that?  Just a thought.

The number of configurations possible is exponential.
However, let's concentrate on providing a skeleton
configuration and the typical configuration used by
90% of the people out there.

I am still interested in an XML file that would
define a configuration. Then we could write a tool
that generates the code for the configuration (so
that we don't have to have an XML parser to create
an XML parser at runtime). In this way, we could
even change what the "standard" configuration is
based on a build option in Ant. [Ted, I thought
you were looking at this. Any progress to report?]

-- 
Andy Clark * IBM, TRL - Japan * 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