In case we want to still make the language schema validatable, the
following is a complete list of issues with the current language which
needs to be fixed.
Properties for the following mediators : Log, Transform, Class
<property name="string" (value="literal" | expression="xpath")/>*
Fault mediator
<code (value="literal" | expression="xpath")/>
<reason (value="literal" | expression="xpath")>
Header mediator
<header name="qname" (value="literal" | expression="xpath")
[action="set"]/>
Filter mediator
<filter (source="xpath" regex="string") | xpath="xpath">
Property mediator
<set-property name="string" (value="literal" | expression="xpath")/>
Extensions:
Spring mediator
<spring:spring bean="exampleBean1" (config="spring1" |
src="spring.xml)"/>
Transform mediator - can be ignored as we do not have xq anyway
<transform (xslt="url"|xquery="url") [source="xpath"]>
Hence if we could agree to change the filter mediator, and allow
properties etc. where a string literal or xpath expression could be
specified to be of the form <property name="string" value="string"
[isexpression="true|false"]> we could get over most of the issues.
asankha
Davanum Srinivas wrote:
Sanjiva,
Since you -1'ed the prev proposal, can you please respond to this one?
thanks,
dims
PS: This has nothing to do with schema validation, just cleaning up
the xml syntax so that *I* can understand it better.
On 7/12/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
Let me try another variation to see if folks like it:
Syntax:
<filter source="xpath" [regex="string"]>
mediator+
</filter>
Explanation:
If the regular expression is present then the <filter> mediator
matches the evaluation result of a source xpath expression against the
given regular expression. If the regex is absent, then the mediator
tests the given source xpath expression as a boolean expression. In
either case, If the test succeeds, the filter mediator will execute
the enclosed mediators in sequence.
Is this any clearer than the text and syntax on the wiki page? [1] or
am i way off base again?
thanks,
dims
[1]
http://wiki.apache.org/incubator/Synapse/SynapseConfigurationLanguage
On 7/12/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> So you come from the XML Schema validation is a good thing camp I
> see ;-).
>
> So I'm generally, always, -1 on changing the language syntax to
make the
> syntax schema validatable. Personally I don't give a damn about
that ..
> let the language do what is best and if XSD can validate, great. If
not
> too bad. In any case, XSD validation is not a really sufficient
> condition - its just a necessary condition and we can easily write a
> schema that is more relaxed than the original to make it pass.
>
> This particular change is ugly IMO .. the use of "@source" is to
> (optionally) identify the source data and xpath vs. regex was the
> pattern that must match.
>
> I think we need to maintain the principle that we design the language
> syntax to be as natural as we can get an ugly XML syntax .. and not
> worry about XSD validation, except if there's a minor tweak that
can be
> done to make something work.
>
> Sanjiva.
>
> On Wed, 2006-07-12 at 18:23 +0530, Asankha C. Perera wrote:
> > Before I post this on the Wiki or proceed any further, I would
like your
> > comments on the following..:
> >
> > The problem is around the existing language syntax which does not
allow
> > us to properly validate a configuration through a schema. Let me
take
> > the filter mediator as an example, and our configuration language
states
> > the following :
> >
> > <filter (source="xpath" regex="string") | xpath="xpath"> mediator+
> > </filter>
> >
> > Shall we change this to
> >
> > <filter xpath="xpath" [regex="string"]> mediator+ </filter>
instead, so
> > that the schema provided for this mediator could be used to
validate a
> > config using it?
> >
> > The same goes for a few mediators as shown in the attached
schema, and a
> > sample file which shows some examples with the proposed syntax.
> >
> > asankha
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
