Hi, As I said even before there is no offence intended towards OM and I also played a part in making it. Any blame on OM falls on me too.
Seems this is becoming to an un-necessary argument, even after the solution being agreed.
Well it is not. An agreement is not implicit and I do not see an explicit agreement in this thread at all. If this is a reference to using DOOM then DOOM has a perfectly fine DOM API and the matter becomes a configuration issue.
Yes, it is. Wasn't it obvious from the first email itself? OM being an fully XML infoset compliant XML object model, don't you expect some one to have schema as an OMElement?
Of course I do expect that to happen . I want to figure out how often that happens and how deep that integration should go. I'll be outlining a possible solution for such cases (Glen would not be very happy with it though)
Anyway, I'd like to conclude this argument as we have a solution with DOOM.
What is the solution in exact terms ? As I said before using DOOM becomes only a configuration issue (change the factory and that should be it ). is that the solution we are talking about ?
> > BTW after numerous encounters I also tend to think that DOM is quite > convenient too (not to offend OM by any means. OM was designed with > perf in mind and DOM was with accuracy in mind). It is 'accurate' and > after a text to DOM conversion you have access to every information > item that was there in text format so atleast that is 'pretty > convenient' for me. Are you saying OM is not giving access to *every* information item as in DOM? And OM is not accurate? If yes, since you are also an OM expert please fix it :).
Ok - I'm getting into a muddy area now. if you compare OM and DOM, DOM has been around much longer and has been hammered on pretty much. This means that it is now failry stable and complete as a piece of software. Unfortunately OM did not get that sort of hammering at all and every now and then you find subtle issues. I do fix bugs as and when I find them but my point is as an API (and an implementation), DOM has proved itself.
OM, from the first day, designed to be convenient for the developer or the user. If there are inconveniences in OM, please bring them up. OM was there for more than 2 years. Why are these "blames" all of a sudden? For me, OM api is far more convenient than the cumbersome DOM api.
Its not a 'blame' and you should not get it personally either :) OM is fine and convenient but if you remember the initial objective of OM was performance. The full infoset support got into the picture later.
> AFAIK XMLSchema strictly depends on the DOM api What is the base to this argument? Do you wanna create another xml-security model which is very in-flexible because its highly dependent on DOM apis.
Ok here is some food for thought. if you are designing an API that needs to be pretty much extensible and it is going to be around for a while AND it is going to have a certain XML API exposed, what is going to be your choice? There are numerous XML object models out there (and OM being one of them) so what would be your pick ? I'm pretty sure that if you pick something other than DOM (the standard) there will be quite a bit of critics on that. IMHO in a third party library standpoint the best choice is DOM and xml-sec people did nothing wrong in making the stuff on DOM. I would say at this point that If I am to do something like the xml-sec thing today, I would not expose the XMLish nature of it. Going with that theory here's the best thing to do with XMLSchema in an extensibility standpoint 1. Define a DOM free interface for the schema builder 2. DOM based schema builder becomes an implementation of that inteface 3. There is a SchemaBuilderFactory that provides builders to the schemaCollection (oops - sorry Glen) 4. Stax based builder can be registered with the factory so that the schema collection picks up that builder. in essence the Stax based builder or the OM based builder lives inside woden (or any other interesting project).
IIUC, Xmlschema depends on DOM when it tries to build the schema model using the SchemaBuilder. This builder builds the schema model, looking at the DOM model. But if there is any attempt to make XmlSchema dependent on DOM, inside its model, other than in the above scenario, expect a -1 from me :).
Well you could put that -1 now if you want to. XML schema serialization completely runs on the DOM API :)
-- Chinthaka
-- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
