You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Asankha C. Perera" <as...@wso2.com> on 2006/07/12 14:53:52 UTC
A few changes proposed for the Synapse Configuration Language
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
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
+1 looks better as well
On 7/12/06, Asankha C. Perera <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
Hadrian,
If we do that then we will have to make sure it is consistent across
the board. i can see several mediator's whose syntax has
source="xpath"
<transform xslt|xquery="url" [source="xpath"]>
<switch source="xpath">
<validate schema="url" [source="xpath"]>
-- dims
On 7/12/06, Hadrian Zbarcea <hz...@gmail.com> wrote:
> +1.
>
> May I suggest changing @source with something imho more self explanatory
> like @test or @match?
>
> Thanks
> Hadrian
>
>
> On 7/12/06, Davanum Srinivas <da...@gmail.com> 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 < sanjiva@opensource.lk> 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:
> synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail:
> synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1.
May I suggest changing @source with something imho more self explanatory
like @test or @match?
Thanks
Hadrian
On 7/12/06, Davanum Srinivas <da...@gmail.com> 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 <sa...@opensource.lk> 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: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: A few changes proposed for the Synapse Configuration Language
Posted by "Asankha C. Perera" <as...@wso2.com>.
Dims
This is done, I have checked in the html into xdocs and linked to it
from the previous wiki page.
thanks
asankha
Davanum Srinivas wrote:
> +1 from me to create a link from wiki to svn.
>
> -- dims
>
> On 7/17/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>> On Mon, 2006-07-17 at 06:41 -0400, Davanum Srinivas wrote:
>> > Asankha,
>> >
>> > wiki is good for discussion. I'd prefer a xml version that can reflect
>> > the work on the trunk.
>>
>> I'd prefer we stick to one place .. otherwise things will guaranteed get
>> out of sync. I'm fine with SVN - I suggest we change the wiki page to a
>> link a viewcvs of the page then though rather than having some out of
>> date page.
>>
>> Sanjiva.
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me to create a link from wiki to svn.
-- dims
On 7/17/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2006-07-17 at 06:41 -0400, Davanum Srinivas wrote:
> > Asankha,
> >
> > wiki is good for discussion. I'd prefer a xml version that can reflect
> > the work on the trunk.
>
> I'd prefer we stick to one place .. otherwise things will guaranteed get
> out of sync. I'm fine with SVN - I suggest we change the wiki page to a
> link a viewcvs of the page then though rather than having some out of
> date page.
>
> Sanjiva.
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-07-17 at 06:41 -0400, Davanum Srinivas wrote:
> Asankha,
>
> wiki is good for discussion. I'd prefer a xml version that can reflect
> the work on the trunk.
I'd prefer we stick to one place .. otherwise things will guaranteed get
out of sync. I'm fine with SVN - I suggest we change the wiki page to a
link a viewcvs of the page then though rather than having some out of
date page.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Paul Fremantle <pz...@gmail.com>.
> Please don't do both - the proper XML way is to use spaces so that the
> schema can be defined properly.
>
> Sure, I will drop the comma
+1
> I thought Ruchith was going to change Rampart to use the sec policy
> stuff instead of using a parameter. In fact the same can be done for the
> JMS stuff .. basically with policy being burnt into Axis2, there's we
> could even completely get rid of the parameter concept. Anyway that's an
> Axis2 discussion.
I would MUCH prefer it if we used policy from Synapse into Axis2 to
configure Axis2. Even if the policy statements are Axis2 specific, its
a more general way of doing it and fits nicely with the Synapse design
point.
> +1. I suggest we don't put <xquery ..> right now - let someone put that
> in when we decide which xquery impl to do it with. No need to pretend we
> have function that we don't have!
>
> Ok.. this will be changed ASAP
Cool
> No - filter either has an (@source *and* @regex) OR (@xpath)
Great - thats what I was hoping.... I just got confused.
> - default value of that is the /s:Envelope (separately I'd like to
> propose a model where that supports SOAP 1.1 and 1.2 both
> simultaneously)
Normally to support the namespace you have to add the xmlns:s
attribute into the filter element, and we then add these to the XPath
processor's namespaces. Maybe we could pre-define soap as a namespace
and unless someone overrides it we can do some clever stuff. i.e. if
the message is SOAP1.1 then soap: refers to the SOAP1.1 namespace and
if the message is SOAP1.2 then it refers to the SOAP1.2 namespace.
If you don't specify a source it should be ok.
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2006-07-18 at 17:04 +0530, Asankha C. Perera wrote:
> Paul
>
> See my comments below
>
> > 1. <proxy>
> >
> > a) We need to be able to specify more than one transport - e.g.
> > transports="jms,http".
> Yes, this is possible.. and default is to enable on all available
> transports (as Axis2) , else you could specify multiple transports
> separated by commas or spaces
Please don't do both - the proper XML way is to use spaces so that the
schema can be defined properly.
> > c) the fact that the properties are really configuring an Axis2
> > endpoint is a little confusing. If we look at it from a general WS-*
> > viewpoint an exposed endpoint has no "properties". I'd like to remove
> > or rename this. I couldn't think of a usecase.
> This was introduced by me to support the following use case.. when a
> service is exposed on JMS, we need to be able to specify a custom
> destination on which it will listen for messages, and a connection
> factory. The new JMS implementation uses these even when used in a pure
> Axis2 environment to configure itself properly
>
> e.g.
> <parameter name="transport.jms.ConnectionFactory"
> locked="true">myTopicConnectionFactory</parameter>
> <parameter name="transport.jms.Destination"
> locked="true">dynamicTopics/something.TestTopic</parameter>
>
> > 2. <endpoint>
> > I'm assuming that the policy tags here will be applied "actively". It
> > would be nice to be able to import a policy: e.g.
> >
> > <endpoint address="http://fremantle.org/service1">
> > <policy src="http://fremantle.org/service1?policy">
> > </endpoint>
> >
> > I would really like some consistency between the use of policy on the
> > <proxy> and <endpoint>.
> Not very clear what you mean as "actively"... right now the policy is
> for RM only.. and Rampart uses a Parameter named "OutflowSecurity"
I thought Ruchith was going to change Rampart to use the sec policy
stuff instead of using a parameter. In fact the same can be done for the
JMS stuff .. basically with policy being burnt into Axis2, there's we
could even completely get rid of the parameter concept. Anyway that's an
Axis2 discussion.
> > 3. I understand that xslt and xquery are both examples of a
> > "transform", but I prefer the syntax:
> >
> > <xslt source="" stylesheet=" "/>
> I'm ok to changing this ... and can do it quickly as we don't yet have XQ
+1. I suggest we don't put <xquery ..> right now - let someone put that
in when we decide which xquery impl to do it with. No need to pretend we
have function that we don't have!
> > 4. I like the filter. There is something missing tho, which is that we
> > used to have two options: one was to find part of the message and
> > apply a regex, the other was to evaluate an xpath expression that
> > resolved to true/false. I'm not sure we can still do the latter. Seems
> > to me we need two clearly formulated options - XPath Source points to
> > string - then regex. XPath expression evaluates to true/false.
> You are correct.. but I'm not sure whether you are referring to the
> 'current' syntax, or the syntax I proposed a few days back... since we
> don't seem to be going ahead with a revision to the schema language,
> what we have 'currently' does exactly what you mention. i.e. it has the
> two options that you mention.
OK let me make sure I understand correctly:
- filter has a "source" property saying what item to filter (xpath or
regex) on
- default value of that is the /s:Envelope (separately I'd like to
propose a model where that supports SOAP 1.1 and 1.2 both
simultaneously)
- in addition, there is EITHER:
- regex: meaning match the regex aganst the text value of whatever
"source"gives .. so clearly if you use regex you must use @source to
point to something interesting .. s:Envelope has no text value
- xpath: a boolean valued xpath which is executed with an xpath context
set to whatever node the source property points to
Is that correct?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by "Asankha C. Perera" <as...@wso2.com>.
Paul
See my comments below
> 1. <proxy>
>
> a) We need to be able to specify more than one transport - e.g.
> transports="jms,http".
Yes, this is possible.. and default is to enable on all available
transports (as Axis2) , else you could specify multiple transports
separated by commas or spaces
> By the way - are these names connected to Axis2 pluggable transports
> or are they a specific synapse keyword?
They are the same Axis2 names
> b) Policy.... as I understand it this is just a pointer to the doc
> that the end user will see if they browse ?policy. It would be nice if
> this was policy that was actively set on the endpoint and used to
> configure the modules.
Yes, this is the service level policy which will apply as you have
mentioned. But we will allow some 'simpler' notation to request the
default QoS module configuration on a proxy service e.g. <enableRM/>
> c) the fact that the properties are really configuring an Axis2
> endpoint is a little confusing. If we look at it from a general WS-*
> viewpoint an exposed endpoint has no "properties". I'd like to remove
> or rename this. I couldn't think of a usecase.
This was introduced by me to support the following use case.. when a
service is exposed on JMS, we need to be able to specify a custom
destination on which it will listen for messages, and a connection
factory. The new JMS implementation uses these even when used in a pure
Axis2 environment to configure itself properly
e.g.
<parameter name="transport.jms.ConnectionFactory"
locked="true">myTopicConnectionFactory</parameter>
<parameter name="transport.jms.Destination"
locked="true">dynamicTopics/something.TestTopic</parameter>
> 2. <endpoint>
> I'm assuming that the policy tags here will be applied "actively". It
> would be nice to be able to import a policy: e.g.
>
> <endpoint address="http://fremantle.org/service1">
> <policy src="http://fremantle.org/service1?policy">
> </endpoint>
>
> I would really like some consistency between the use of policy on the
> <proxy> and <endpoint>.
Not very clear what you mean as "actively"... right now the policy is
for RM only.. and Rampart uses a Parameter named "OutflowSecurity"
> 3. I understand that xslt and xquery are both examples of a
> "transform", but I prefer the syntax:
>
> <xslt source="" stylesheet=" "/>
I'm ok to changing this ... and can do it quickly as we don't yet have XQ
> 4. I like the filter. There is something missing tho, which is that we
> used to have two options: one was to find part of the message and
> apply a regex, the other was to evaluate an xpath expression that
> resolved to true/false. I'm not sure we can still do the latter. Seems
> to me we need two clearly formulated options - XPath Source points to
> string - then regex. XPath expression evaluates to true/false.
You are correct.. but I'm not sure whether you are referring to the
'current' syntax, or the syntax I proposed a few days back... since we
don't seem to be going ahead with a revision to the schema language,
what we have 'currently' does exactly what you mention. i.e. it has the
two options that you mention.
thanks
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Paul Fremantle <pz...@gmail.com>.
Folks
A few comments.
Firstly, I think we should validate the syntax within Synapse and not
using XSD validation. XSD is ok, but it seems like its making the
design more complex, and that doesn't seem worth it.
Secondly, I'm looking through the latest config XML right now and have
some comments.
1. <proxy>
a) We need to be able to specify more than one transport - e.g.
transports="jms,http".
By the way - are these names connected to Axis2 pluggable transports
or are they a specific synapse keyword?
b) Policy.... as I understand it this is just a pointer to the doc
that the end user will see if they browse ?policy. It would be nice if
this was policy that was actively set on the endpoint and used to
configure the modules.
c) the fact that the properties are really configuring an Axis2
endpoint is a little confusing. If we look at it from a general WS-*
viewpoint an exposed endpoint has no "properties". I'd like to remove
or rename this. I couldn't think of a usecase.
2. <endpoint>
I'm assuming that the policy tags here will be applied "actively". It
would be nice to be able to import a policy: e.g.
<endpoint address="http://fremantle.org/service1">
<policy src="http://fremantle.org/service1?policy">
</endpoint>
I would really like some consistency between the use of policy on the
<proxy> and <endpoint>.
3. I understand that xslt and xquery are both examples of a
"transform", but I prefer the syntax:
<xslt source="" stylesheet=" "/>
4. I like the filter. There is something missing tho, which is that we
used to have two options: one was to find part of the message and
apply a regex, the other was to evaluate an xpath expression that
resolved to true/false. I'm not sure we can still do the latter. Seems
to me we need two clearly formulated options - XPath Source points to
string - then regex. XPath expression evaluates to true/false.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
Asankha,
wiki is good for discussion. I'd prefer a xml version that can reflect
the work on the trunk.
thanks,
dims
On 7/17/06, Asankha C. Perera <as...@wso2.com> wrote:
> Dims
>
> Right now the latest Synapse Configuration Language docs are on the wiki
> (http://wiki.apache.org/incubator/Synapse/InProgress/SynapseConfigurationLanguage)
> as we are not changing the docs for M2..and currently some changes are
> taking place. Shall I place the Wiki src for the above page under Xdocs
> instead of its XML/Html?
>
> thanks
> asankha
>
> Davanum Srinivas wrote:
> > Asankha,
> >
> > Could you please check in a version (html or xml) to svn under xdocs?
> > So that we can track the changes. I'd like to help rewrite some of the
> > sentences to better describe what the functionalities are. Let's nail
> > it down then see if we want to do the xsd thing or not.
> >
> > thanks,
> > dims
> >
> > On 7/15/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >> We'll have to ask Asankha what he had in mind .. in my mind it was
> >> always that @source was used to select what to apply the filter to and
> >> xpath or regex were ways of filtering.
> >>
> >> Sanjiva.
> >>
> >> On Fri, 2006-07-14 at 21:19 -0400, Davanum Srinivas wrote:
> >> > Hi,
> >> >
> >> > Forget about XSD and validation....Am just trying to decipher the
> >> > intent from the verbiage / examples on the wiki page...Please bear
> >> > with me. I think i am getting the point. But just for clarification.
> >> >
> >> > #1: The example on the page says:
> >> > <filter xpath="//*[wsx:symbol='MSFT']"
> >> xmlns:wsx="http://www.webserviceX.NET/">
> >> >
> >> > So you are saying that it is implicitly
> >> >
> >> > <filter source="/soap:Envelope" xpath="//*[wsx:symbol='MSFT']"
> >> > xmlns:wsx="http://www.webserviceX.NET/">
> >> >
> >> > Because you need to run the xpath on something and that something is
> >> > the soap envelope. Right?
> >> >
> >> > #2: If #1 is true, then the syntax on the wiki has an implicit source,
> >> > but one cannot specify a source explicitly when xpath is specified.
> >> > Right?
> >> >
> >> > Thanks,
> >> > dims
> >> >
> >> > On 7/14/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >> > > On Wed, 2006-07-12 at 13:00 -0400, Davanum Srinivas 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.
> >> > >
> >> > > This is not what @source means .. it identifies the data to
> >> filter; the
> >> > > "source" for filtration. If @source is missing, the data is
> >> > > the /soap:Envelope element. If its there it can point to any
> >> place in
> >> > > the message and then the regex or xpath matches against that node.
> >> > >
> >> > > So your proposal has lost function.
> >> > >
> >> > > Again, I'm -1 to the *principle*: If the language syntax is bust
> >> let's
> >> > > fix it. But let's *not* convolute the syntax to make a nice(r)
> >> schema.
> >> > >
> >> > > Sanjiva.
> >> > >
> >> > >
> >> > >
> >> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> >> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by "Asankha C. Perera" <as...@wso2.com>.
Dims
Right now the latest Synapse Configuration Language docs are on the wiki
(http://wiki.apache.org/incubator/Synapse/InProgress/SynapseConfigurationLanguage)
as we are not changing the docs for M2..and currently some changes are
taking place. Shall I place the Wiki src for the above page under Xdocs
instead of its XML/Html?
thanks
asankha
Davanum Srinivas wrote:
> Asankha,
>
> Could you please check in a version (html or xml) to svn under xdocs?
> So that we can track the changes. I'd like to help rewrite some of the
> sentences to better describe what the functionalities are. Let's nail
> it down then see if we want to do the xsd thing or not.
>
> thanks,
> dims
>
> On 7/15/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>> We'll have to ask Asankha what he had in mind .. in my mind it was
>> always that @source was used to select what to apply the filter to and
>> xpath or regex were ways of filtering.
>>
>> Sanjiva.
>>
>> On Fri, 2006-07-14 at 21:19 -0400, Davanum Srinivas wrote:
>> > Hi,
>> >
>> > Forget about XSD and validation....Am just trying to decipher the
>> > intent from the verbiage / examples on the wiki page...Please bear
>> > with me. I think i am getting the point. But just for clarification.
>> >
>> > #1: The example on the page says:
>> > <filter xpath="//*[wsx:symbol='MSFT']"
>> xmlns:wsx="http://www.webserviceX.NET/">
>> >
>> > So you are saying that it is implicitly
>> >
>> > <filter source="/soap:Envelope" xpath="//*[wsx:symbol='MSFT']"
>> > xmlns:wsx="http://www.webserviceX.NET/">
>> >
>> > Because you need to run the xpath on something and that something is
>> > the soap envelope. Right?
>> >
>> > #2: If #1 is true, then the syntax on the wiki has an implicit source,
>> > but one cannot specify a source explicitly when xpath is specified.
>> > Right?
>> >
>> > Thanks,
>> > dims
>> >
>> > On 7/14/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>> > > On Wed, 2006-07-12 at 13:00 -0400, Davanum Srinivas 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.
>> > >
>> > > This is not what @source means .. it identifies the data to
>> filter; the
>> > > "source" for filtration. If @source is missing, the data is
>> > > the /soap:Envelope element. If its there it can point to any
>> place in
>> > > the message and then the regex or xpath matches against that node.
>> > >
>> > > So your proposal has lost function.
>> > >
>> > > Again, I'm -1 to the *principle*: If the language syntax is bust
>> let's
>> > > fix it. But let's *not* convolute the syntax to make a nice(r)
>> schema.
>> > >
>> > > Sanjiva.
>> > >
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
>> > >
>> > >
>> >
>> >
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
Asankha,
Could you please check in a version (html or xml) to svn under xdocs?
So that we can track the changes. I'd like to help rewrite some of the
sentences to better describe what the functionalities are. Let's nail
it down then see if we want to do the xsd thing or not.
thanks,
dims
On 7/15/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> We'll have to ask Asankha what he had in mind .. in my mind it was
> always that @source was used to select what to apply the filter to and
> xpath or regex were ways of filtering.
>
> Sanjiva.
>
> On Fri, 2006-07-14 at 21:19 -0400, Davanum Srinivas wrote:
> > Hi,
> >
> > Forget about XSD and validation....Am just trying to decipher the
> > intent from the verbiage / examples on the wiki page...Please bear
> > with me. I think i am getting the point. But just for clarification.
> >
> > #1: The example on the page says:
> > <filter xpath="//*[wsx:symbol='MSFT']" xmlns:wsx="http://www.webserviceX.NET/">
> >
> > So you are saying that it is implicitly
> >
> > <filter source="/soap:Envelope" xpath="//*[wsx:symbol='MSFT']"
> > xmlns:wsx="http://www.webserviceX.NET/">
> >
> > Because you need to run the xpath on something and that something is
> > the soap envelope. Right?
> >
> > #2: If #1 is true, then the syntax on the wiki has an implicit source,
> > but one cannot specify a source explicitly when xpath is specified.
> > Right?
> >
> > Thanks,
> > dims
> >
> > On 7/14/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > > On Wed, 2006-07-12 at 13:00 -0400, Davanum Srinivas 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.
> > >
> > > This is not what @source means .. it identifies the data to filter; the
> > > "source" for filtration. If @source is missing, the data is
> > > the /soap:Envelope element. If its there it can point to any place in
> > > the message and then the regex or xpath matches against that node.
> > >
> > > So your proposal has lost function.
> > >
> > > Again, I'm -1 to the *principle*: If the language syntax is bust let's
> > > fix it. But let's *not* convolute the syntax to make a nice(r) schema.
> > >
> > > Sanjiva.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
We'll have to ask Asankha what he had in mind .. in my mind it was
always that @source was used to select what to apply the filter to and
xpath or regex were ways of filtering.
Sanjiva.
On Fri, 2006-07-14 at 21:19 -0400, Davanum Srinivas wrote:
> Hi,
>
> Forget about XSD and validation....Am just trying to decipher the
> intent from the verbiage / examples on the wiki page...Please bear
> with me. I think i am getting the point. But just for clarification.
>
> #1: The example on the page says:
> <filter xpath="//*[wsx:symbol='MSFT']" xmlns:wsx="http://www.webserviceX.NET/">
>
> So you are saying that it is implicitly
>
> <filter source="/soap:Envelope" xpath="//*[wsx:symbol='MSFT']"
> xmlns:wsx="http://www.webserviceX.NET/">
>
> Because you need to run the xpath on something and that something is
> the soap envelope. Right?
>
> #2: If #1 is true, then the syntax on the wiki has an implicit source,
> but one cannot specify a source explicitly when xpath is specified.
> Right?
>
> Thanks,
> dims
>
> On 7/14/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > On Wed, 2006-07-12 at 13:00 -0400, Davanum Srinivas 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.
> >
> > This is not what @source means .. it identifies the data to filter; the
> > "source" for filtration. If @source is missing, the data is
> > the /soap:Envelope element. If its there it can point to any place in
> > the message and then the regex or xpath matches against that node.
> >
> > So your proposal has lost function.
> >
> > Again, I'm -1 to the *principle*: If the language syntax is bust let's
> > fix it. But let's *not* convolute the syntax to make a nice(r) schema.
> >
> > Sanjiva.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
Hi,
Forget about XSD and validation....Am just trying to decipher the
intent from the verbiage / examples on the wiki page...Please bear
with me. I think i am getting the point. But just for clarification.
#1: The example on the page says:
<filter xpath="//*[wsx:symbol='MSFT']" xmlns:wsx="http://www.webserviceX.NET/">
So you are saying that it is implicitly
<filter source="/soap:Envelope" xpath="//*[wsx:symbol='MSFT']"
xmlns:wsx="http://www.webserviceX.NET/">
Because you need to run the xpath on something and that something is
the soap envelope. Right?
#2: If #1 is true, then the syntax on the wiki has an implicit source,
but one cannot specify a source explicitly when xpath is specified.
Right?
Thanks,
dims
On 7/14/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Wed, 2006-07-12 at 13:00 -0400, Davanum Srinivas 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.
>
> This is not what @source means .. it identifies the data to filter; the
> "source" for filtration. If @source is missing, the data is
> the /soap:Envelope element. If its there it can point to any place in
> the message and then the regex or xpath matches against that node.
>
> So your proposal has lost function.
>
> Again, I'm -1 to the *principle*: If the language syntax is bust let's
> fix it. But let's *not* convolute the syntax to make a nice(r) schema.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-07-12 at 13:00 -0400, Davanum Srinivas 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.
This is not what @source means .. it identifies the data to filter; the
"source" for filtration. If @source is missing, the data is
the /soap:Envelope element. If its there it can point to any place in
the message and then the regex or xpath matches against that node.
So your proposal has lost function.
Again, I'm -1 to the *principle*: If the language syntax is bust let's
fix it. But let's *not* convolute the syntax to make a nice(r) schema.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by "Asankha C. Perera" <as...@wso2.com>.
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 <da...@gmail.com> 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 <sa...@opensource.lk> 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: synapse-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
>> >
>> >
>>
>>
>> --
>> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
>> Developers)
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
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 <da...@gmail.com> 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 <sa...@opensource.lk> 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: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Davanum Srinivas <da...@gmail.com>.
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 <sa...@opensource.lk> 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: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A few changes proposed for the Synapse Configuration Language
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org