Asankha Could you please post an overall description of how the XSD validation is planned to work. I realise now I'm re-reading the chat that I didn't get it!
Paul On 7/6/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
Here is a list to a sample XSD we generate http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD as mentioned below * Now talking in #apache-synapse * paulfremantle has joined #apache-synapse <asankha> hi Paul * ant has joined #apache-synapse <ant> hi <asankha> hi Ant <paulfremantle> hi <ant> Did you get back from apachecon with out too much trouble? <asankha> we did.. though we missed one flight, we were able to get on the next one.. <paulfremantle> so <paulfremantle> i know its quiet today <paulfremantle> a couple of things <paulfremantle> 1) ant - did you read the registry wiki i posted <paulfremantle> that was the final point asankha and i got to on friday <ant> actually not yet in great detail. I'll do that right after this chat <paulfremantle> ok <paulfremantle> theres really three parts to it <paulfremantle> 1) being able to bootstrap "properties" from an external xml - either src (just a URL) or key (a "reg" lookup) * saminda has joined #apache-synapse <saminda> hi all <paulfremantle> hi * hzbarcea has joined #apache-synapse <paulfremantle> hi hadrian <hzbarcea> hi <paulfremantle> 2) instead of mediators loading XML from outside they can get it from properties <asankha> hi hadrian <hzbarcea> hi everybody <ant> hi <paulfremantle> 3) if we pull it from a "registry" then its dynamic but cached <ant> ok. that all sounds good <paulfremantle> and we had some idea of how we could cache any "compilation" <paulfremantle> e.g. a script or XSLT <asankha> we should be able to get something working by next week on these lines.. so that we can refine it <paulfremantle> cool <hzbarcea> I have a question <paulfremantle> shoot! <hzbarcea> what are the rules with the wiki site <paulfremantle> rules? <paulfremantle> wiki? <hzbarcea> i created an account yesterday and i would like to update some pages <paulfremantle> afaik anyone can edit pages <hzbarcea> but i am not a commiter <hzbarcea> technically yes <paulfremantle> go ahead :-) <hzbarcea> thx <paulfremantle> we'd welcome the help <asankha> yes.. it'll be great to get the documentation reviewed <asankha> do not change the main pages though... but whats in the "InProgress" section... <hzbarcea> i thought that as i learn i could capture the knowledge somewhere <asankha> unless its a typo etc.. <hzbarcea> no, not the main page, of course <hzbarcea> and anybody could revert my changes and give me a yellow card if you don't like it :) <asankha> you could create new pages as well inside http://wiki.apache.org/incubator/Synapse/InProgr ess and link from there <paulfremantle> so the other thing i wanted to discuss today was how we use policy <asankha> yep <paulfremantle> so now we are adding rm and sec support <paulfremantle> it would be good to have a common way of configuring those <paulfremantle> for both incoming (proxy) and outgoing (endpoints) <paulfremantle> so I am in favour of using <paulfremantle> <wsrmp:RMAssertion> <paulfremantle> in other words the actual ws policy <paulfremantle> but that might be a little complex in some cases <paulfremantle> so how about we let you do <paulfremantle> EITHER <paulfremantle> 1) the full WS-Policy (including any Sandesha/Rampart extensions) <paulfremantle> or <paulfremantle> 2) an alias: <syn:enableRM>, <syn:enableWSS> <paulfremantle> in which case it takes the default from the underlying config of sandesha or rampart * ant_ has joined #apache-synapse <ant_> hi, sorry PC crashed <paulfremantle> when? <ant_> when the converstation about updating the wiki started <ant_> did i miss anything? <asankha> i guess so.. about the WS RM and Sec discussion <paulfremantle> [13:20] hzbarcea: thx <paulfremantle> [13:20] asankha: yes.. it'll be great to get the documentation reviewed <paulfremantle> [13:21] asankha: do not change the main pages though... but whats in the "InProgress" section... <paulfremantle> [13:21] hzbarcea: i thought that as i learn i could capture the knowledge somewhere <paulfremantle> [13:21] asankha: unless its a typo etc.. * paulfremantle has quit IRC (Excess Flood) <asankha> hmm... seems like NW trouble for all :-) * paulfremantle has joined #apache-synapse <asankha> <paulfremantle> so now we are adding rm and sec support <asankha> <paulfremantle> it would be good to have a common way of configuring those <asankha> <paulfremantle> for both incoming (proxy) and outgoing (endpoints) <asankha> <paulfremantle> so I am in favour of using <asankha> <paulfremantle> <wsrmp:RMAssertion> <paulfremantle> ha <asankha> <paulfremantle> in other words the actual ws policy <asankha> <paulfremantle> but that might be a little complex in some cases <asankha> <paulfremantle> so how about we let you do <asankha> <paulfremantle> EITHER <asankha> <paulfremantle> 1) the full WS-Policy (including any Sandesha/Rampart extensions) <asankha> <paulfremantle> or <asankha> <paulfremantle> 2) an alias: <syn:enableRM>, <syn:enableWSS> <asankha> <paulfremantle> in which case it takes the default from the underlying config of sandesha or rampart <paulfremantle> i tried posting it but it disconnected me :-) <asankha> i think you posted too much in one go :-) <asankha> Ant.. thats the part you missed.. so we can go on Paul <paulfremantle> that was it! <hzbarcea> i agree that using thw <wsrmp:RMAssertion> is a good way to go as its semantic is clear <hzbarcea> but since one has to instantiate the mediator <hzbarcea> isn't it ok to use a wrapper <hzbarcea> which wraps the assertion if you want to replace the default <hzbarcea> as in <asankha> well.. actually what Paul is describing is not a mediator.. we "will" have a mediator to perform RM/Sec too <paulfremantle> yes thanks asankha <hzbarcea> <enableRM/> - use the deffault <hzbarcea> or <enableRM> <hzbarcea> <wsrmp:RMAssertion> ... <asankha> The idea is that you can request enabling of RM/Sec on an Endpoint or Proxy using the above mentioned Tags within the Proxy or Endpoint Tags <paulfremantle> i wasnt clear.... this is a subelement of <proxy> or <endpoint> <hzbarcea> </enableRM> <paulfremantle> really what i was thinking was <paulfremantle> <endpoint> <paulfremantle> <policy> <paulfremantle> <wsx:xpolicy/> <ant_> by default do you mean a Synapse global WSRM or WSSec default? <paulfremantle> </policy></endpoint> <paulfremantle> But <paulfremantle> I figured maybe we could just bypass the <policy> tags <paulfremantle> to make it simple <paulfremantle> well neethi (policy framework) has all kinds of clever inheritance stuff <paulfremantle> so possibly we could make things inherit defaults from the parent <paulfremantle> or maybe we keep the <policy> tag <paulfremantle> if you use the full version <paulfremantle> and <enableRM/> is an alias for <policy><wsrmp:RMAssertion/></policy> * Retrieving #apache-synapse modes... <paulfremantle> so in either <endpoint> or <proxy> you could have <paulfremantle> <policy> any ws policy at all </policy> <paulfremantle> <endpoint><enableRM/><enableWSS/></endpoint> * ant has quit IRC (Read error: 110 (Connection timed out)) * ant has joined #apache-synapse <asankha> yes.. i guess the common case is that usually WS-sec for each Proxy/Endpoint would be different.. and how we would specify those security properties <paulfremantle> then in that case you'd have to use the full policy <ant> sorry, NW problems so I'd dropped out again. carry on though i'll catch up when the log is posted <paulfremantle> if you come on again we'll have 3 ants <paulfremantle> which is nearly a colony <ant> LOL <paulfremantle> asankha do you think that will work <ant> i've an off topic question if you've finished with WS-* things <asankha> yes.. i guess it will.. <paulfremantle> go ahead ant <asankha> but i dont think we can specify things like the keystore and identity etc to be used for a sec operation through policy.. or can we? <ant> the mediator interface now has a getType method. I wondered if that was really necessary or could be put somewhere else? <paulfremantle> yes im not sure we need that <paulfremantle> on the mediator <paulfremantle> maybe on the mediatorfactory? <asankha> ant.. thats a good question.. let me explain why i need it <asankha> actually paul we have it on the mediator factory <asankha> the mediator factory now returns the XML schema for its mediator <asankha> so the schema fragment usually defines a complex type like <mediator>_type <asankha> and we need to include this type as a valid choice for the mediator_type complex type which is defined as follows <asankha> <xs:complexType name="mediator_type"> <asankha> <xs:sequence maxOccurs="unbounded"> <asankha> <xs:choice> <asankha> <xs:element name="send" type="synapse:send_type"/> <asankha> <xs:element name="drop" type="synapse:drop_type"/> <asankha> .... <asankha> <xs:element name="in" type="synapse:in_type"/> <asankha> <xs:element name="out" type="synapse:out_type"/> <asankha> </xs:choice> <asankha> </xs:sequence> <asankha> </xs:complexType> <asankha> so that the schema would be valid and complete <paulfremantle> couldn't we just do an <xs:any> at that point <asankha> but the problem is.. the "mediator_type" complex type is defined programmatically looking at the available extensions <paulfremantle> to handle the extension <asankha> well.. thats what i wanted to do first.. <asankha> but this way you wont be able to validate them <paulfremantle> true <asankha> you cannot define a choice with <xs:anyType> <ant> what do you mean "the mediator factory now returns the XML schema", which class/method are you talking about so i can go look? <asankha> the other option is to always expect the complex type name to be "<mediator>_type" <asankha> and thats what we do for the core mediators... if you extend from the Abstract <paulfremantle> asankha I'm still not clear how we can validate if someone has plugged in their own extension <hzbarcea> you can if xs:any if from namespace="##other" <asankha> shall i post the draft synapse.xsd i have and a sample XML to the mailing list.. and we could all try it out, suggest and decide? <paulfremantle> great <hzbarcea> i have a quick q <hzbarcea> are there any tools for synapse or any plans for tools? <hzbarcea> gui and/or other stuff <asankha> i just posted a quick copy of a generated schema.. http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD <paulfremantle> not yet Hadrian <paulfremantle> we would like to get the base stable first <asankha> for example.. look at this <asankha> <xs:complexType name="spring_type"> <asankha> <xs:attribute name="bean" type="xs:string" use="required"/> <asankha> <xs:attribute name="config" type="xs:string"/> <asankha> <xs:attribute name="src" type="xs:string"/> <asankha> </xs:complexType> <asankha> we also have spring_type as a possible choice in the mediator_type (as I said before) <paulfremantle> the problem is that this isn't extensible <asankha> so now you can validate a config with the spring mediator <paulfremantle> if I write a paul.jar that adds support for the paul mediator <paul src="http://fremantle.org/paul.xml"/> <paulfremantle> then how can we validate? <asankha> your PaulMediatorFactory should expose something like follows... <asankha> a method public XmlSchema getTagSchema(); which exposes your schema "fragment" <asankha> something like whats below.. <asankha> <xs:complexType name="spring_type"> <asankha> <xs:attribute name="bean" type="xs:string" use="required"/> <asankha> <xs:attribute name="config" type="xs:string"/> <asankha> <xs:attribute name="src" type="xs:string"/> <asankha> </xs:complexType> <paulfremantle> ok <paulfremantle> and then? <asankha> and then the public QName getTagSchemaType() should state the complex type name that defines your mediator in the above schema <paulfremantle> but we cannot use "pure XSD" validation <asankha> i.e. "spring_type" for above <paulfremantle> outside of Synapse <asankha> you mean on the paul.jar file? <paulfremantle> i mean that if I have the schema plus a validator tool <paulfremantle> I can't just run it <paulfremantle> Synapse can because synapse could extract all the schema fragments and validate the whole <paulfremantle> but a standard XSDValidator couldnt' <asankha> well.. yes.. <asankha> we actually have the mediator_type and property_type common types in a common place <paulfremantle> maybe we should build an option into Synapse.bat to validate the config <asankha> but we could ship the synapse.xsd for the core mediators <asankha> and anyone could import it and use it <asankha> we can do that.. that brings me to the second problem i encountered :-) <asankha> XmlSchema uses Xalan underneath... <asankha> which we do not ship by default with the synapse core release! <asankha> so right now i have it generate the schema's only if Xalan and its dependencies (Xerces) are available.. and issue a WARN if not <asankha> since it will still enable you to run Synapse without a problem <asankha> but if the dependenceis are met.. it will work fine and also be able to validate <asankha> I guess thats the best for right now is it Paul? or do we begin to get Xalan into our code dependencies set? <paulfremantle> hmmmm <paulfremantle> its a shame <paulfremantle> maybe we should ask the xmlschema guys if theyu can do without it <asankha> well.. interestingly thats one of the main objectives of the XmlSchema according to the web page... * ant_ has quit IRC (Read error: 113 (No route to host)) <asankha> but i guess they need to reuse as opposed to reinvent the wheel <asankha> :-( <paulfremantle> mmm <asankha> lets look at this during the coming week and decide next week how we want to progress? <paulfremantle> yes <paulfremantle> i have to go as well <asankha> yes.. i think we had a good discussion today .. <paulfremantle> i need to look through the schema stuff <paulfremantle> yes thanks <paulfremantle> +1 <asankha> hopefully Ant will catch it up too.. <asankha> ok.. see you all later.. i will post this to the mailing list <ant> yes. I've only just sync SVN now and seen all the schema stuff... <ant> Paul, we've a Tuscany chat at 5pm if you wantt o come along <paulfremantle> cool <paulfremantle> i will if i can <ant> (and anyone else if you're interested) <paulfremantle> :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
