[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: The DOM: the realist and the implementer
Hi Ray, Ray said: What do you feel is needed beyond the current W3C DOM standard methods for querying the levels and modules of support in a DOM implementation? Didier reply: Simple. An interface (even defined in OMG IDL) that allows clients to query the provider DOM level support. Ray said: COM/DCOM is already anticipated to divide into separate interfaces for expansion, because that is how that object model handles expansion. Different models/bindings have the freedom to expand in the way most suitable to the binding. Don't expect every other language to follow suite, for example in Javascript where expansion is simply done directly to the object -- even if it is just COM objects supplying the implementation because an IDispatch approach is taken to supply a non-segmented interface if I understand it correctly. Didier reply: It seems that you missed something Ray. I'll be more explicit and just do this simple experiment Ray. a) use, as you said, the actual DOM IDL interface definition as a template and create a C++ interface with virtual members. This is only if your compiler creates a structure containing pointers to functions. Right there, it means that you choused a specific binary signature for your component. If you publish this binary signature convention, an other component that wants to interface with your component will have to be able to use this binary signature. So, right there you have to choose for a practical interface - a binary signature - for your component. b) obviously your components would have to be packaged as a shared library on certain platforms and as DLL on others c) Now that you made all these choice. Play the following game: 1) create a client component with an interface that added new members. To be practical, let's say that the original interface was: class test { void virtual member1() = 0; void virtual member2() = 0; } Remember that you made the choice that your binary signature is a struct containing pointers to functions (an arbitrary one, you may choose an other kind of binary signature). If you are lucky enough that you compiler creates that with the above construct then we are OK. Otherwise, you may have to implement it yourself with a C struct. if lucky enough with your class, derive from it and just make an implementation of each member having a dummy content like printing or displaying the member name. 2) now, that you have created a component providing a service, let' now create a client having this interface: class client { void virtual member1() = 0; void virtual member2() = 0; void virtual member3() = 0; } Question: will this client component work with the provider we created? Obviously no. ---> Here is what I mean with the notion of contract. Conclusion: If we say that the DOM has to be available in any kind of languages. Actually, the weakness is that the IDL specification chosen was created for remote invocation not for in-process usage. Right there, the is an impedance mismatch between the definition and the usage (except if you want to access a DOM provider at the other end of the globe). So, the usage of an OMG IDL is not necessarily judicious and may have been justified by politicial pressure ( I can understand that, after all W3C is a consortium of vendor, not a representant of users needs). Nonetheless, most of DOM usages are intra-adress space usage. Thus, the missing parts are: a) defining the interfaces with at least an IDL and set of specification that defined a particular binary signature so that components can _really_ talk together within the same address space. I do not say here that the interfaces should not be defined with the OMG IDL. Someone may have the need to ask for a DOM service at the other end of the globe :-)). Or to compile and convert the document in a DOM in an address space and use it in an other. b) Defining at least one interface that allows the client to probe the DOM provider. This interface is a fixed contract and do not change. This way, the client can query the DOM version throught a permanent interface that do not vary in time. Then, the client can, from the information received with that interface use the provider or not. Practically speaking, the client may understand only DOM 1, the provider may only support DOM 2, then the client cannot inter-operate with the provider. case 2: the client only understand DOM1, the provider supports both set of interfaces, the user may obtain the right interface set from the provider. Even if each interface do not have a query interface mechanism, the provider may provide the right set of interfaces. Note about the query interface on each node: you know that the DOM is, in some ways, an implementation of the composite pattern (gamma & al. 1995). Let's say that you have a root interface used to query the DOM version and obtain the root node. if the elements of the DOM where designed to support a query interface mechanism, then the root interface may, in this case, return a node interface. Now let's say that the DOM is an ever evolving entity and that in year 2020 the root node is not anymore the "document" node. Then, in this case, if the returned node is simply a "node" and that a query interface mechanism is provided, then I can query the "node" for the kind of interface desired, in 2020 that may probably by a "library" interface :-) Actually, within the current interface definitions I can't. I have to request for a "document" node, if this evolves into a library object, then its over, the contract is not respected any more. The best solution is to provide to the client a "node" object and then from this object obtain either a "document" or a "library" interface. This time the contract works. But, let's be indulgent and say that if at least a non changing interface is provided then a query interface on each interface is not necessary, the client will know that DOM level-124 (in year 2020) starts with a "library" interface not a "document" interface. So, in that case, the non-changing interface should return a typeless interface...hummmm, is that against the OMG interface principles. There we go, maybe here, a potential Y3K bug in view :-))) We can also say that the interfaces are simply templates, that the IDL was used only to please the OMG consortium and that in fact, the IDL is a fad not to be used in real life. OK, if the recommendation say that I should not take the IDL for an implementation but only as an inspiration, this is at least clear that I should not use the IDL for a DOM implementation. Also, if implicitely it is said that I can do whatever I want with the interfaces, add or suppress members, then why do we have recommendations then? I hope that now you see the incongruity of the situation. Anyway, my proposal is not to judge the DOM WG which had to deal with enough political pressure from its members. But to help us create truly inter-operable components by providing enough information to implementers so that at least, they know what the contract is and how to fulfill it. And most of all, to provide to users components that are inter-operable, at least, within the same middleware convention. This is not even the case today with the actual DOM recommendations. Cheers Didier PH Martin ---------------------------------------------- Email: martind@n... Conferences: Web New York (http://www.mfweb.com) Book to come soon: XML Pro published by Wrox Press Products: http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1 Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|