[XML-SIG] XSLT parser interface

[Uche Ogbuji]

> > > module XPath{
> > >   // XSLT exprType values
> > >   const unsigned short PATTERN = 17;
> > >   const unsigned short LOCATION_PATTERN = 18;
> > >   const unsigned short RELATIVE_PATH_PATTERN = 19;
> > >   const unsigned short STEP_PATTERN = 20;
> 
> > I think we might want to space out these module-level constants a
> > bit to allow for user extension.
> 
> We might want to do so for future revisions of XPath itself, so this
> is a good idea.
> 
> > Or should all extensions use numbers above a certain ceiling?
> 
> This is the general problem with a numeric type identification: you
> need UUIDs or otherwise not-conflicting strings (like the IDL
> repository IDs). However, this kind of identification appears to be
> W3C tradition. So requesting that user extensions use another range
> seems reasonable.

How about users get numbers above 1000?

> > Some of these take an approach that's a bit cute (for instance, the
> > boolean parent idea), but since it's really a developer-only
> > interface, this should be fine.
> 
> No, please suggest a more natural interface - I'm no XSLT expert at
> all. The XPath tradition seems to be that everything with // is called
> "abbreviated", so it would be

Not quite.  Abbreviated is any abbreviation, "//" just being one (abbr for 
'/descendant-or-self::node()/').

I think what might be throwing you off is the inconsistent modularization in 
4XPath.  The various Parsed* classes were pretty much thrown into modules at 
random without much inconsistency, and it makes things like "Abbreviated" take 
on significance that they shouldn't have.

I've wanted to clean this up for a while, but we've always been short on time. 
 I think your confusion and the changes we're making are good enough reason to 
finally neaten things up.

Here are my suggested mods to your interface


  interface PatternFactory:ExprFactory{
    Pattern createPattern(in LocationPathPattern first);
    // idkey or step must be null
    // if left is null, it's an absolute pattern
    LocationPathPattern locationPathPattern(in locationPathPattern left,
					    in locationPathPattern right,
                                            in StepPattern step,
                                            in FunctionCall idkey);

    StepPattern createStepPattern(in AxisSpecifier axis,
				  in NodeTest test,
				  in PredicateList predicates);
  };

I'm not even sure of this.  I'll want to talk some things over with Mike and 
Jeremy tomorrow.  For one thing, I wonder whether we don't have too many 
"Parsed*" classes.  Some things look as if they could be parameterized in 
combined classes.  For instance, the separation of "Absolute*".


Also, I wonder whether in the general case, the parser should expand 
abbreviations, or whether they should be reported as is to the engine.  My 
first inclination is to make the parser do the expansion.

> but that does not sound much better. I don't mind revising my
> implementation, I did so a number of times when coming up with the
> interface initially.

Yes.  One thing about the messy XPath BNF is that it doesn't suggest a model 
very straightforwardly.

> BTW, I find the grammar part of XSLT worded much worse than the one in
> XPath. E.g. there is no apparent concern for lexical issues, like when
> 'id' should be considered as an NCName and when it should be the
> pseudo-keyword of an IdKeyPattern.

We've often wondered about this part ourselves.  It looks as if they are 
trying to make a distinction between "id" and "key" and other function calls 
at a syntactic layer, when IMO it should be at the semantic layer.  This 
wouldn't be so bad if the XPath parser state machine wasn't already so chaotic.

> > I forgot whether Expr defines a pprint method.  If not, I think it
> > should.
> 
> It currently does not have anything except for the bare data
> model/abstract syntax. Adding methods would be the next step;
> I just added
> 
>   DOMString pprint();
> 
> to Expr. Evaluation needs more thought - atleast for me.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python