[XML-SIG] Announcing PyXPath 1.2
Martin v. Loewis
martin@mira.cs.tu-berlin.de
Sun, 28 Jan 2001 13:43:33 +0100
> > const unsigned short BINARY_EXPR = 8;
> Since there are two basic types of binary expressions, I suggest
> splitting this into a BOOLEAN_EXPR and NUMERIC_EXPR. They do offer
> quite different functionality.
Sounds good. How does the UNION_OPERATOR fit in?
> > const unsigned short UNARY_EXPR = 9;
> This would be considered a NUMERIC_EXPR.
How do you represent a '-x' in a NumericExpr object, then?
In particular, how to distingiush 'a-b' and '-a'? The first
is
createNumericExpr(MINUS_OPERATOR, a, b)
Some options for the second one:
createNumericExpr(UNARY_MINUS_OPERATOR, a, None)
createNumericExpr(UNARY_MINUS_OPERATOR, None, a)
createNumericExpr(MINUS_OPERATOR, a, None)
createNumericExpr(MINUS_OPERATOR, None, a)
Which one would you prefer?
> > // the name must still contain the leading $
> > VariableReference createVariableReference(in DOMString name);
>
> name can be a qualified name. use prefix, localname
Ok.
> > Literal createLiteral(in DOMString literal);
> > Number createNumber(in DOMString value);
> > FunctionCall createFunctionCall(in DOMString name, in ExprList args);
>
> See createVariableReference
Ok.
> > Expr parseLocationPath(in DOMString path); // returns absolute or relative path, or step
>
> This should probably be parseExpression, since the Expr is the primary
> construct. (See XPath spec - sect 1)
Probably. I'm still not sure certain which start symbol is required in
what applications. For the moment, I dropped parseLocationPath in
favour of parseExpr.
> > interface AbsoluteLocationPath:Expr{
> > /* '/' relative-opt, or '//' relative */
> > readonly attribute Expr relative; // step or relative path
>
> relative may be null (case of '/')
Sure. That is implied in all cases where the grammar has option
constructs.
> > const unsigned short ANCESTOR = 1;
> > const unsigned short ANCESTOR_OR_SELF = 2;
> > const unsigned short _ATTRIBUTE = 3; // attribute is a keyword
> > const unsigned short CHILD = 4;
> > const unsigned short DESCENDANT = 5;
> > const unsigned short DESCENDANT_OR_SELF = 6;
> > const unsigned short FOLLOWING = 7;
> > const unsigned short FOLLOWING_SIBLING = 8;
> > const unsigned short NAMESPACE = 9;
> > const unsigned short PARENT = 10;
> > const unsigned short PRECEDING = 11;
> > const unsigned short PRECEDING_SIBLING = 12;
> > const unsigned short SELF = 13;
>
> Maybe suffix the types with '_AXIS'?
All of them? Ok.
> > interface AxisSpecifier:Expr{
> > readonly attribute unsigned short name;
>
> Should we use axisType just for consistancy?
In the grammar, the non-terminal collecting them is AxisName, so I'm
not sure what consistency really means here.
> > const unsigned short COMMENT = 1;
> > const unsigned short TEXT = 2;
> > const unsigned short PROCESSING_INSTRUCTION = 3;
> > const unsigned short NODE = 4;
>
> suffix of '_NODE_TEST' ??
So we get NODE_NODE_TEST? Try again :-)
> > interface NodeTest:Expr{
> > readonly attribute unsigned short test;
>
> testType ??
Ok. I guess that also means we get axisType.
[...]
> > const unsigned short BINOP_UNION = 14;
>
> possibly ??_OPERATOR as apposed to BINOP_??
Ok.
> > UnaryExpr createUnaryExpr(in Expr exp);
> >
> See factory functions above.
Changed (using createNumericExpr(MINUS_OPERATOR, exp, None) instead).
I'll release PyXPath 1.3 soon, which will also include a proposal for
integration of XSLT match expressions. Then I'll try to patch
4XPath/4XSLT to use PyXPath. I won't change the attribute names in
4XPath to conform with the IDL, though, atleast for the moment.
Regards,
Martin