Re: Abstract Pattern Processing Model

(I know this was 3 weeks back but no-one replied to Dan, and its quiet 
in here)

Daniel wrote:
 > It"s not clear from the specification how should the abstract pattern be
 > processed. Specifically, given that a node can only be evaluated by 
one rule
 > inside a pattern, the processing order matters. Therefore, if a patterns
 > specifies is-a pointing to an abstract pattern that contains further 
rules,
 > which ones should be processed first?

This can't happen - the RelaxNG schema contains the restriction that 
parameterized patterns (pattern[@is-a]) cannot contain rules

 > Is there a way to make the following more explicit in 6.2 Simplified
 > Syntax?:
 > "- Resolve all abstract patterns by replacing parameter references with
 > actual parameter values"
 >
 > I think the simplified syntax for this should be the direct inclusion 
of all
 > rules in the abstract pattern at the beginning of the inheriting pattern
 > declaration, and considering all parameter references as if they were 
<let>
 > elements. This is because the syntax for parameter and variable 
references
 > in most languages is the same.

The syntax may be the similar, but the intent is different. I think this 
part of the spec is terribly unclear, but <param> elements read to me as 
describing preprocessing directives, like #define in C/C++[1]. eg the 
spec describes the param values as 'fragments of queries' and that they 
can be resolved to the simplified syntax giving an equivalent schema - 
if param values were xpaths or xqueries they couldn't be removed without 
reference to an instance document (it was trying to implement this that 
made the penny drop for me). Finally, the order of param elements is not 
considered important, so param values cannot reference other params 
(unlike lets). To my mind this is 'circumstantial evidence' of what 
these are for in the spec, rather than an explicit statement of what 
they're for - I'd like to see this bit cleared up.

Anyway, seen in this light, the sentence in 6.2 makes more sense.

-Baz

[1] not precisely like #define because they are ordered - param's 
semantics must be more like this: (in a perl syntax - makes the regexp 
bit easy):
    $delimiter = "\$";
    @keys = keys %param;
    # a canonical param order ensures lexical param order doesnt matter
    # reverse order puts 'aaa' before 'aa' so both keys will work correctly
    @keys = sort &reverse @keys;
    # nasty perlisms... I just mean ('aaa', 'aa') -> "$aaa|$aa"
    $regexp = join '|', map { "$delimiter$_" } @keys;
    # split into 'normal text' plus param keys with their delimiter, in 
order.
    @pieces = split /($regexp)/ , $query;
    # build the result
    $result = "";
    foreach $piece (@pieces) {
       # look for and remove delimiter
       if ($piece=~s/^$delimiter/) {
          # matched - replace piece with the param
          $piece = $param{$piece};
       }
       $result .= $piece;
    }



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click