Paul and Asankha, Agreed, yeah, even though my suggestion makes it easy for the computer to process it easily it makes that a bit difficult to wrtie. 100% agreed.
Then if the user wants to know weather a particular element is a mediator or not he has to use a list of known mediators in non java spaces. I also think it is good over making it difficult to write the configuration for human.... Thanks for figuring this out. Ruwan. On 12/14/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
Ruwan I agree with Paul although I like the technical approach you describe here. Using multiple namespaces would require one to define them with prefixes and use the correct ones when writing a configuration by hand - which might incur an additional burden. asankha Paul Fremantle wrote: > Ruwan > > Can you please post a more detailed example of what the synapse config > language would look like? > > I think there is a challenge which is that you want to make it easier > for a machine to read.... but maybe harder for a human to write! I'm > not convinced that is the right balance. > > Paul > > On 12/13/06, Ruwan Linton <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Currently we have a common namespace for every element used within a >> synapse >> configuration. >> >> This is ok when we are processing the configuration with Java (as the >> MediatorFactory that loads the mediators knows each available >> mediator), but >> if someone wants to process this configuration as XML (for example using >> javascript) then he/she has a set of XML elements with the same >> namespace >> and he/she will not be able to distinguish between mediator elements >> and the >> non-mediator elements such as endpoints etc. unless we maintain a >> list of >> mediators to compare with the known element names. This also is >> difficult >> when we use an XSLT processor to process our configuration. >> >> To overcome this issue I think it is better to change the namespace of >> mediators from the general synapse namespace so that one can compare the >> namespace of the element and figure out whether it is a mediator >> element or >> not. >> >> Any comments.... >> >> Thanks, >> Ruwan. >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
