Abstract pattern processing model

"Daniel Cazzulino" <[email protected]> Wed, 30 Jun 2004 14:56:45 -0300
Newsgroups gmane.text.xml.schematron
Organization Lagash Systems SA
Message-ID <[email protected]>
This is a multi-part message in MIME format.

------=_NextPart_000_0118_01C45EB2.7D3FCF60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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? The base abstract pattern rules or the
concrete pattern ones? I guess it should be the former, but that should be
stated in the spec. 
 
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. In XPath/XSLT, for example it's the $ sign
followed by either the parameter or variable name. In programming languages,
you refer to them directly by name.
Don't know, however, if it's acceptable to asume this.
 
This "inclusion" resolution is the same used for rules in the simplified
syntax, that's why I though it may be useful to have the same processing
model for patterns.

------=_NextPart_000_0118_01C45EB2.7D3FCF60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.3790.118" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial size=3D2>It's =
not clear from=20
the specification how should the abstract pattern be processed. =
Specifically,=20
given that a node can only be evaluated by one rule inside a pattern, =
the=20
processing order matters. Therefore, if a patterns specifies is-a =
pointing to an=20
abstract pattern that contains further rules, which ones should be =
processed=20
first? The base abstract pattern rules or the concrete pattern ones? I =
guess it=20
should be the former, but that should be stated in the spec.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial size=3D2>Is =
there a way to=20
make the following more explicit in 6.2 Simplified =
Syntax?:</FONT></SPAN></DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial size=3D2>"- =
Resolve all=20
abstract patterns by replacing parameter references with actual =
parameter=20
values"</DIV></FONT></SPAN>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial size=3D2>I =
think the=20
simplified syntax for this should be the direct inclusion of all rules =
in the=20
abstract pattern at the beginning of the inheriting pattern declaration, =
and=20
considering all parameter references as if they were &lt;let&gt; =
elements. This=20
is because the syntax for parameter and variable references in most =
languages is=20
the same. In XPath/XSLT, for example&nbsp;it's the $ sign followed by =
either the=20
parameter or variable name. In programming languages, you refer to them =
directly=20
by name.</FONT></SPAN></DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial size=3D2>Don't =
know, however,=20
if it's acceptable to asume this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D111384817-30062004><FONT face=3DArial size=3D2>This =
"inclusion"=20
resolution is the same used for rules in the simplified syntax, that's =
why I=20
though it may be useful to have the same processing model for=20
patterns.</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0118_01C45EB2.7D3FCF60--




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com