[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: So, to restate the question, what is the problem with the "hasFeature" call of DOM? Didier reply: I already explained all this in a previous post on XML-dev. to restate it briefly: a) case one: we banish everything that is not Java, JavaScript or created with a CORBA IDL because everything else is not defined in the DOM recommendation. This is not very practical since there is alternative middleware or other languages than the one listed. b) we consider the DOM recommendation as a template. The data types may vary (the DOMString is only an example, string may be different in different languages) but, we use the DOM as a template. As long as the function names are respected and that we can package these functions is something that resemble an interface (i.e. an object, etc...) it is OK. So, let's now say that it is (B). It will be an interpretation since it is not explicitly said anywhere. Contrary to that, everywhere in the recommendation is displayed CORBA interfaces so, this may lead to think that this is the official religion and other stuff is heresy. Anyway, let's play the supreme court judges and say that our jurisprudence is that the DOM recommendation are simply templates are that the CORBA interfaces are simply guidelines. If that is the case, if we want something quite general, and because the interfaces definitions change from recommendation to recommendation and therefore any contract between clients and providers is changing. Then, the proposal is made that, a new interface (i.e. a template, not a C++ template :-)) is added to the DOM recommendation. At least, the DOM component providers on certain early binding environments like for instance XPCOM or DCOM or whatever can implement this interface to announce the support level. This way, no more crashes. Off course, certain late binding environment may not have this problem, in that case this interface may be superfluous. However, if we agree on a certain non changing interface to announce the DOM component capabilities, this may be useful on certain platform. Let's make a concrete proposal (again the interface here is based on the (b) interpretation and could be taken as a template) interface DOMComponent { boolean HasFeatures(....); // we have here the same parameters as in the DOM specifications object QueryDOM(DOMString); // could be actually "DOM1" or "DOM2" returns an object (i.e. could be actually a "document" interface and in year 2020 a "library" interface. so we say here an untyped object. Each platform may adapt this to its world. } Thus, a client first ask for this interface to query for the capabilities, then obtain with the QueryDOMInterface the first node. The algorithm is: a) Obtain the DOMComponent interface (in XPCOM or DCOM get it from the class factory) b) Get the DOM component capabilities with the HasFeatures member c) if the required feature is present, then use the QueryDOM. We could have said here queryDOM interface or QueryDOMObject. But in some environment it may be an object for other an interface, so let's make it more neutral with QueryDOM. This latter member returns an object (i.e. an interface). As long as this interface do not change in time, we are OK, an XPCOM or DCOM DOM client using early binding won't experiment a crash. This could also be said of an OSF RPC but, there not a lot of these in the field ( :-)) Thus, a WINE implementation of a DOM component may provide this interface and prevent client crashes, idem for an XPCOM client. As long as this interface do not change. But, instead of adding this interface we have always the alternative to say that XPCOM and DCOM is heresy and that everybody that is using that should be burned in hell. If that is the case, please, give me at least some time to email my fellow colleagues at Mozilla.org to ask for a refugee status :-))) PS: I have read your page on CROS and look forward reading more an hopefully experimenting with it in the future. 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
|