[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: The DOM and the victim, the iconoclast and the believer
Hi David, I did not made that test with Java but I think that if I do a call to an interface's member that does not exist, Java throw an exception. Am I right to say that? So, in the case of Java, we have to implement an exception handler for non supported members if we want our code to be robust when consuming a DOM component. If that is the case, let me think of the advantage of having each time an exception handler for non-supported members compared to an interface providing the DOM capabilities. On the first thinking pass, I do not see any advantages. So, even if CORBA do support exception handling (1), to use such mechanism to discover the capabilities is not quite good. However, if I understand you well, you propose to use Node.getOwnerDocument().getImplementation().hasFeature() for such service. Did I understood well? If that is the case, I am not able to find the member "getImplementation" in the DOM specs. Or maybe, you make a proposal for capability discovery here, is it the case? This implies that we modify again the node interface to add the member "getimplementation". Or maybe you meant the "support" member that appeared in DOM 2. So, in fact, we can probe for the right capabilities only since DOM2. Let's wrap this up. a) Actually, if I understand you well, CORBA has for early binding (as well as for late binding) a mechanism for impedance mismatch between components. if a member is called and not present in the interface, an exception is thrown. So far, so good for CORBA implementations. b) Now for DCOM or XPCOM implementations. a) we consider them out of the recommendation or non compliant to DOM1 and DOM 2 recommendations since the interfaces are not encoded in the CORBA IDL and mapped with a CORBA compliant ORB to a language (for instance C++). b) we consider DCOM and XPCOM as a compliant implementations and if this is the case, then, we have a problem since DCOM do not throw exceptions for early binding, only for late binding. And XPCOM is for the moment only for early binding. Then, in that case we have a problem with impedance mismatch. c) if only a CORBA compliant implementation is compliant with the DOM recommendations then the Mozilla XPCOM or Microsoft or WINE DCOM implementation of the DOM is non compliant and therefore cannot be called a DOM 1 or DOM 2 compliant implementation since it is not implemented nor distributed with a CORBA compliant ORB. If that is the case, only a CORBA compliant implementation is OK, a Java implementation is OK and a JavaScript is OK. Everything else not developed with CORBA compliant ORB is not OK. Then, is java and JavaScript specifications OK even if not generated nor distributed with a CORBA ORB? Gee, there are some contradictions here d) The ORB IDL and the java and JavaScript specifications where just example. There is no obligation to use a CORBA IDL to generate the right code. The proof of this is that there is no actual CORBA to JavaScript mapper (Is there any?). IN that case, there exist component specifications such as XPCOM or DCOM for early binding that may crash if an impedance mismatch occurs between the provider and the consumer. In that case, and mainly for early binding, a new non changing interface is required to probe for capabilities. Obviously we have to provide a mechanism which is backward compatible. Thus, this mechanism has to allow a client to probe for level one or level two support (or level n). This even if the DOM 2 recommendation included in the node interface such probing mechanism but this mechanism is not part of DOM1, therefore, it is not backward compatible and may cause problems to COM component consumers, especially the consumers using an early binding mechanism. So, basically, either we bannish forever XPCOM and DCOM implementations (goodby WINE, goodby Mozilla) saying that they do not fit in the CORBA, java or javaScript world. or that we say that these where only templates, examples. In this case, we need a non changing interface for consumers to probe the DOM component capabilities. This mechanism has to work for any DOM implementation since the DOM 1 recommendation. David, I am having a hard time to know what is and what is not compliant now. However, if an XPCOM or a DCOM implementation could be said to be compliant to a DOM 1 or DOM 2 recommendation, then we need an interface that does not change to query the DOM capabilities since the node interface seems to change at each DOM recommendation. And, with XPCOM and DCOM early binding client, I will get a crash if the wrong interface is addressed. Off course, I can say that the client is responsible to deal with any situation, etc... but why not make life easier and have a single place telling the client what kind of contract is supported by the provider. And again, in the case of XPCOM or DCOM implementations, and if these latter are said to be compliant DOM implementations, then this is required since these component protocol cannot handle interfaces that change all the time. PS: thanks for the tips about interface inheritance. ---------------------- (1) I am still searching where it is written for early binding - For late binding, this is obviously the case - I want to put an hand on the exact location in the specs where it is written for future references. 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
|