Re: Grammar-caching: proposal for moving forward

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

Hi Andy,

>"Description" seems like the wrong name for this interface.
The methods don't describe the object that implements this
interface. Rather, it is a location of a resource. So what do
you think of changing the interface to XMLResourceLocation
(or something similar)?

So we have XMLLocator which extends XMLResourceLocation.  Seems a little
odd, but I can live with it.  Should we also change XMLGrammarDescription
to XMLGrammarLocation?

> Also, I would add an additional method to the interface that
returns the expanded system identifier. This relates to James
Clark's bug report #5070 -- what he refers to as the "actualURI".
In his bug report he states, rather appropriately, that even
though the callback gives you the baseSystemId and systemId,
it requires every application to expand the ID when this code
is already a part of the parser.

>Therefore, I would suggest adding a method, like the following:

>  public String getExpandedSystemId();

>So, if the baseSystemId is "http://example.org/document.xml"
and the systemId is "dtd/grammar.dtd", then the expanded
systemId would be "http://example.org/dtd/grammar.dtd".

There's a bug report current detailing a problem we have with the SAX
Locator#getSystemId() call.  It's quite clear from the documentation that
this call intends the systemId to be expanded.  So, to make our interface
beasy to learn for SAX programmers, I wonder whether we should rather have

     public getOriginalSystemId() // returns non-expanded systemId
     public String getSystemId() // get expanded systemId

What do you think?  IMHO would have been much better if SAX hadn't named
things this way, but they have ,for better or worse...

>> - XMLGrammarDescription needs to be added somewhere (probably to
>   xni.parsers, but I'm unsure here);

>I'm not sure that this needs to be part of XNI. There's nothing
in XNI about grammar parsing (outside of DTD scanning) or grammar
caching -- that is an implementation detail. And as such, this
interface should be part of the implementation package, *not* in
XNI.

This is surely no more an implementation detail than error handling or
entity resolution--which are part of XNI.  I think overriding our default
implementation will be far too common a use-case to make folks dig around
in our impl package to find the GrammarPool interface they need to
override.  What's gained by keeping this out of XNI--isn't it fair to
expect any parser that implements XNI to make provisions for grammar
caching?  So I'm still strongly of the view that both GrammarPool and
XMLGrammar(Location|Description) need to live somewhere in the xni
hierarchy.

I'd be happy to see them relegated to a special package if you're happier
with this though; I just can't think of a good name.

But it does look like we're converging on a pretty neat set-up, and that
*is* great to see!

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: Grammar-caching: proposal for moving forward

[Edwin Goei <ed...@sun.com>]

neilg@ca.ibm.com wrote:
> 
> There's a bug report current detailing a problem we have with the SAX
> Locator#getSystemId() call.  It's quite clear from the documentation that
> this call intends the systemId to be expanded.  So, to make our interface
> beasy to learn for SAX programmers, I wonder whether we should rather have
> 
>      public getOriginalSystemId() // returns non-expanded systemId
>      public String getSystemId() // get expanded systemId
> 
> What do you think?  IMHO would have been much better if SAX hadn't named
> things this way, but they have ,for better or worse...

Or since it's XNI, we could make the name unambiguous:
getExpandedSystemID() and getLiteralSystemID().  The fact that SAX
expects the expanded systemID could be added to the javadoc.

If it hasn't already, I think the SAX Locator#getSystemID() bug needs to
be fixed.

BTW, I haven't looked in detail on the other parts of your post.

-Edwin

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

Re: Grammar-caching: proposal for moving forward

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

neilg@ca.ibm.com wrote:
> So we have XMLLocator which extends XMLResourceLocation.  Seems 
> a little odd, but I can live with it.  Should we also change 
> XMLGrammarDescription to XMLGrammarLocation?

What do you think of the alternate name I suggested in my
previous post? (XMLResourceIdentifier)

> There's a bug report current detailing a problem we have with 
> the SAX Locator#getSystemId() call.  It's quite clear from the 
> documentation that this call intends the systemId to be expanded.  
> So, to make our interface beasy to learn for SAX programmers, I 
> wonder whether we should rather have
> 
>      public getOriginalSystemId() // returns non-expanded systemId
>      public String getSystemId() // get expanded systemId

I agree with your assessment. Unfortunately, that is how the
SAX getSystemId is documented to work because they don't report
both pieces of information.

> This is surely no more an implementation detail than error 
> handling or entity resolution--which are part of XNI.  I think 
> overriding our default [...]

I beg to differ. Error handling and entity resolution is
fundamental. Validation and grammar caching is not.

> implementation will be far too common a use-case to make folks 
> dig around [...]

It may be common for the minority of users that want to
override the default grammar caching facility. But that
doesn't mean that it should be added to XNI and be made
a requirement for all XNI parsers.

> override.  What's gained by keeping this out of XNI--isn't it 
> fair to expect any parser that implements XNI to make provisions 
> for grammar caching?  So I'm still strongly of the view that 
> both GrammarPool and [...]

I don't think so. I look at all of the parser configurations 
I have written (and will write in the future) and I have yet 
to find a need for validation or grammars of any kind.

> I'd be happy to see them relegated to a special package if 
> you're happier with this though; I just can't think of a good 
> name.

This may be a solution. I would rather take a more 
measured approach, though. Add the interfaces to the
implementation packages while we perfect and finalize
them. Then move them to an XNI extension package if
needed.

> But it does look like we're converging on a pretty neat set-up, and that
> *is* great to see!

"I love it when a plan comes together." :)

-- 
Andy Clark * 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