[XML-SIG] XSLT parser interface

[Martin v. Loewis]

> > 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.

> Minor nit, but it puzzled me for a few seconds.  the comman above
> should be a colon, or just rephrase to
> 
> "If idkey is non-Null, this is an IdKeyPattern

Ok.


> 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

    /* rel/step */
    RelativePathPattern createRelativePathPattern(in RelativePathPattern rel,
						  in StepPattern step);
    /* rel//step */
    AbbreviatedRelativePathPattern createAbbreviatedRelativePathPattern
                      (in RelativePathPattern rel, in StepPattern step);

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.

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.

> 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.

> Other than that, looks great.

Thanks!

Martin