Cart
|
[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: I did not see an explanation of that before, nor do I see one below. You were proposing something that seems very equivalent to hasFeature. Didier reply: Sorry Ray, it seems that the problem is out of range of your understanding. I do not not now what is the something that you do not understand. Maybe before going further you can read a bit about XPCOM (ref: http://www.mozilla.org) or DCOM (choice here get the doc at microsoft site or code for Linux at WINE site which URL I do not remember) Yes it indeed keep the same kind of result as HasFeature but resolve the problem for XPCOM and DCOM early binding DOM component. Ray said: Add to this, that players in each domain SHOULD standardize their specific bindings. It does less good if there are multiple COM implementations out there. I mention COM because there apparently _are_ multiple incompatible COM implementations out there. To the best of my knowledge, no independent implementor of the spec tried to sit down at the beginning and write up the COM binding as an open public standard, so we can expect that they are not interoperable. Blame the W3C if you like for not wanting to explicitly produce every standard binding, but the generic standard already moves slowly enough without the added weight. I place the blame on COM DOM implementors who had interoperability as a requirement and failed to follow through with a standards document. It should have been obvious as they privately made up interface and class identifiers and did not standardize them with others making similar efforts that they would not be interoperable. If they did not have interoperability as a requirement, then that speaks volumes by itself. If they thought it was W3C's responsibility, well, they were mistaken. They should have at least published a note to the W3C, and I still hope someone does so that all the other implementations can be judged as private tinkering never designed to be interoperable, and implementations designed to be interoperable will be. Didier reply: Yes I agree with you Ray, I ven asked several month ago (or years?) why is the COM IDL not included in the recommendations and got fuzzy answers denoting some political issues behind the answers (surely not technical ones). Off course, my intent is to ûblicaly publish a COM and XPCOM idl so that ambiguity is resolved once and for all (hopefully, I do not have 30 000 people working for me nor do I have billions in revenus but at least has the decency to provide my component users a clear contract). Ray said: They are much stronger than guidelines, but they cannot reasonably dictate all the idiosyncrasies that a particular language or object model binding has to establish in order to accomplish interoperability. That has to be done language-by-language. It must be standardized to be effective. That doesn't mean that W3C ever intended to do all the work for all bindings themselves. The tools are there, but the standards work only starts when a DOM spec is released. Please note that this attention is required regardless of the level 2 issues of adding methods to interfaces. It had to start with level 1, or it certainly won't work with level 2. Didier reply: For any CORBA compliant ORB these interface definitions are implementable, for everything else, only templates. Ray said: Seems quite unwieldy and unnecessary to me. While this is similar to how COM solves the issue, it seems unnecessary in Javascript, for example. There is less arbitrary or haphazard modification to DOM interfaces than your posting implies. A Java, COM, Perl, Javascript, or other DOM binding can be extended for level 2 without too much trouble such that a level 1 application never knows the difference, while not subjecting the user to unreasonable crossed-over baggage from other object models. Counterexamples will be gladly examined. There already are mechanisms in DOM for solving these situations where they crop up, but "core" functionality is "core" so that the application doesn't have to wonder with every new node whether it is available. I find it extremely unworkable to have to query node-by-node for core functionality. Didier reply: Who said node by node you? surely not me read again the posting. I said an interface to query the capabilities of the component. Not an interface to be added to any interface. Most of all, it is not all middleware that does support the queryInterface mechanism. So, let's forget it. The only sufficient thing is to provide an interface that the client where the client can query the component capabilities, obtain the first node (which as I said can change in times - ref: example of the actual "document" root which could eveolve into the "library" root node). After you get the root node (of wahtever class or type if may become) you have what the actual or current recommandation states. The mechanism is only to provide for early binding middleware a non changing interface so that client can probe the component capabilities without experimenting any crash. Off course, new middleware as your can provide a better answer than XPCOM or COM but it remains that for those using these middleware, a robust solution has to be provided. And this solution is not to tell them, go buy or use a CORBA ORB. Ray said: Something like this is fine for COM. I don't think I would choose exactly your model, even for COM after having heard lots of arguments. And it is clearly inappropriate for some languages. Didier reply: OK ray, what would you propose for COM then. I am listening. Hoops I forgot, your solution has also to work with XPCOM too. OK, I am all hears to what you'll say. Ray said: This is not at all what was being proposed. It is proposed that COM extend the interfaces in a way that COM is designed to be extended, and that others do the same, adequately standardizing and publishing the required binding-specific details to make it interoperable. How methods are added is only one of many issues. Didier reply: What are you talking about Ray? You said that, I never proposed this. I am trying to find a solution for a problem experimented with DCOM and XPCOM based components (using early binding) and propose a solution which is better than a system crash to know if the component provides or not the service. We could have used the CLSID but this does not necessarily work with XPCOM. So, the solution is a compromise for both world. 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
|
|||||||||
