synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <>
Subject Re: SynapseObject - Reminder...
Date Thu, 02 Mar 2006 11:05:42 GMT
More comments inline!

The second is more readable, simpler and easier to modify. I'm certainly not
> suggesting that we HAVE to use Schema, but the fact is that you CAN validate
> with Schema whereas XML1 you cannot validate that the CI data is correct,
> only that generic format is right. This is equivalent to XML well-formedness
> checking which is much weaker.
> [Soumadeep] Correction, we can validate XML1
> <pzf>Validating XML1 is equivalent to checking well-formedness in XML2.
Very little value.</pzf>

> : we haven't put the validate method yet ... the xsd is at the end of the
> email. It will validate whether it conforms to the SO structure.  It also
> gives you the facility to have a secondary xsd which will validate if the SO
> instance is of type "ConsumerIdentification" or any other mediators specific
> xml.
> <pzf>This validation is MUCH more complex, and probably requires
non-standard tools.</pzf>

> From a readability point of view, I think XML1 gives you more visibility
> in terms of containment and attribution.
> <pzf>I absolutely do not agree.</pzf>

As per XML2 the validation has to go through an XSD, whereas in case SOs the
attributes are type conscious.

<pzf>You can make XML2 type aware if you like. There is a standard:

<mynumber xsi:type="xs:integer">23</mynumber>.


Regarding point 2, I wasn't suggeting that every mediator writer had to make
> an effort. There is no effort in doing reflection, because the code already
> exists in our Axis2 framework. Please look at
> org.apache.axis2.databinding.ADBBean
> and
> org.apache.axis2.databinding.util.BeanUtil
> This simple code will automatically write a bean out as XML:
>         QName q = new QName("", "SimpleBean" );
>         StAXOMBuilder b = new
> StAXOMBuilder((XMLStreamReader)BeanUtil.getPullParser(sb,q));
>         OMElement el = b.getDocumentElement();
>         System.out.println(el);
> and this even simpler code will automatically read in a bean from XML
> using ADB:
> SimpleBean sb2 = (SimpleBean)BeanUtil.deserialize(SimpleBean.class,
> omelement);
> I urge you to take a look at the ADB framework.
> [Soumadeep] Same can be achieved by SOs , plus *the search* functionality
> that it already has.
> <pzf>You can use full XPath on the OMElements out of the box on XML1,
which is as powerful and more</pzf>

> Secondly, SOs are interchangeable meaning you can still use the xml
> representation (the conversion function is available in SO getXMLFragment)
> and also have XSD based validation as suggested by you.
<pzf> I don't understand this statement</pzf>

[Soumadeep] Another thing that you mentioned earlier was using xpath for
> search. Well, true you can use it but the problem is then the xpath
> expressions have to be generated/written by users and maintained by them in
> case the xml changes, whereas this overhead is not there with the SOs.
<pzf>If you change the structure of the XML you may or may not have to
change the code. Xpath expressions can be flexible enough to support

[Soumadeep] Another advantage you get out of SO is that it's got a generic
> data structure so mediators developers will at least have a notion of how to
> handle it. The use of this structure will be very helpful when others add
> mediators in an existing chain of mediators.
<pzf>XML is a flexible data structure. You are just reinventing XML *INSIDE*

[Soumadeep] SOs also have generic setters and getters such as,
> getString("Foo") as against getFoo();
> <pzf>ADBs have typed getters and setters, and also have well defined Java
types. </pzf>


Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

"Oxygenating the Web Service Platform",

View raw message