Subject: Tiny incompatibility between DOM Core Level 2 and DOM Core Level 3 - msg#00058List: web.dom.generalHi everyone, Here's a minor issue in the DOM Level 2 and Leve 3 specifications that has nothing to do with browser compatibility (for a refreshing change of pace!): DOM Level 2 calls for the following exceptions for createDocument: INVALID_CHARACTER_ERR: Raised if the specified qualified name contains an illegal character. NAMESPACE_ERR: Raised if the qualifiedName is malformed, if the qualifiedName has a prefix and the namespaceURI is null, or if the qualifiedName has a prefix that is "xml" and the namespaceURI is different from "http://www.w3.org/XML/1998/namespace"; [Namespaces]. DOM Level 3 calls for the following: INVALID_CHARACTER_ERR: Raised if the specified qualified name is not an XML name according to [XML 1.0]. NAMESPACE_ERR: Raised if the qualifiedName is malformed, if the qualifiedName has a prefix and the namespaceURI is null, or if the qualifiedName is null and the namespaceURI is different from null, or if the qualifiedName has a prefix that is "xml" and the namespaceURI is different from "http://www.w3.org/XML/1998/namespace"; [XML Namespaces], or if the DOM implementation does not support the "XML" feature but a non-null namespace URI was provided, since namespaces were defined by XML. These appear to call for different exceptions in certain cases. For example, a qualifiedName that is the empty string should throw NAMESPACE_ERR per DOM Level 2 (it does not contain any characters and so cannot "contain an illegal character", but the qualifiedName is indeed malformed). But it would throw INVALID_CHARACTER_ERR under DOM Level 3. Is there any value to resolving this inconsistency somehow? Right now the DOM Level 2 test suite is testing for the DOM Level 3 behavior on this, which seems wrong, as the test suite is testing for a behavior expressly contrary to the corresponding spec. On the other hand, testing for the L2 behavior would mean that passing the L2 test suite would preclude L3 compliance. Curt Arnold mentioned that he thought there might have been a decision to do an erratum to Level 2 on this, which through some oversight never got published, and suggested mailing this list. Regards, Maciej
Thread at a glance:
Previous Message by Date: (click to view message preview)Re: [dom3core] WRONG_DOCUMENT_ERROn Friday 2005-12-02 19:05 -0700, Ray Whitmer wrote: > On Dec 2, 2005, at 12:26 PM, Maciej Stachowiak wrote: > >Firefox has the implicit adoption behavior. I am surprised you > >don't know. > > Expect me to continue to respond to your ongoing jabs with my own > questioning of your own knowledge, if I continue to respond at all. > > I am relatively certain Firefox does not have implicit adoption in > some cases and therefore benefits from exceptions being thrown, as I > have explained several times now. Now, should I say that I am or Mozilla trunk and 1.7 branch throw WRONG_DOCUMENT_ERR in exactly one case: when DOMImplementation::createDocument is called with a non-null doctype parameter whose ownerDocument is non-null. That said, the implicit adoption behavior may not be bug-free. -David -- L. David Baron <URL: http://dbaron.org/ > Technical Lead, Layout & CSS, Mozilla Corporation pgpLEAM4LQTJH.pgp Description: PGP signature Next Message by Date: click to view message previewRe: [dom3core] WRONG_DOCUMENT_ERROn Dec 3, 2005, at 2:51 AM, Maciej Stachowiak wrote: Hi Ray, On Dec 2, 2005, at 6:05 PM, Ray Whitmer wrote: On Dec 2, 2005, at 12:26 PM, Maciej Stachowiak wrote: Firefox has the implicit adoption behavior. I am surprised you don't know. Expect me to continue to respond to your ongoing jabs with my own questioning of your own knowledge, if I continue to respond at all. My apologies. I didn't mean this to come out as rude as I am sure it sounded. I was also frustrated by the uniformly negative tone of replies to my messages. I proposed errata to the spec originally because Curt Arnold suggested this approach to compliance vs. compatibility conflicts in the test suite(*). But now even he seems critical of this approach. * - See e.g. http://bugzilla.opendarwin.org/show_bug.cgi?id=4569 Curt Arnold in bug 4569: This may be another one to raise to the IG. The test as written is consistent with the Java implementations, the original NIST tests and my reading of the recommendation. However, I do not believe any browser raises the WRONG_DOCUMENT_ERR, though I'm not sure what they do in that situation. There may be a case for an errata to change the phrasing to "May be raised" based existing implementations with corresponding changes to the tests. --- Any disputes about the test suite go to the IG for resolution. The NIST tests and my reading of the spec said it was required and without direction from the IG, I would not modify the tests. However, if the IG said that I misread the recommendation, I would modify the test suite on their direction. I said "there may be a case", I didn't say there'd be a compelling case or I'd agree with it. You presented a case, most comments have been negative but I think everybody here is sympathetic with the problem, just not the proposed solution of changing the expected behavior. Unfortunately with the WG over, the process to come up with a better solution or dismiss the issue is uncertain. If WRONG_DOCUMENT_ERR is optional, we potentially open up another set of problems, since the spec writers (probably) and the test writers definitely did not consider the potential scenarios that could occur when a node is inserted in another document. Do we know that the current implementations that don't throw an exception implement the same behavior. Maybe one does an importNode type action and another does an adoptNode type of action. It would be reasonable to think that the original spec writers did not want to try to think through the issues that would be required to freely move nodes between documents and decided that the most expedient approach to make sure that implementations were consistent was to prohibit it. Alternative solutions have been suggested and I don't know if you've stated your thoughts on them. The ones that I remember off the top of my head were: A Note that describes were ECMAScript implementations generally deviate from the recommendation for compatibility with existing content. A configuration option in the browser that would allow the user (likely developer) to change between standard conformant and compatibility mode. Previous Message by Thread: click to view message previewspecificity of style rule?Hi Everyone, I'm brand new to the list. I wonder: is there a way to know the specificity of a cssRule? Can I get some number representing the weight? Example: <style> #foo { } p { } </style> <script> var cssRules = document.styleSheets[0].cssRules; if(cssRules[0].weight > cssRules[1].weight) { } <script> -- http://dhtmlkitchen.com/ Next Message by Thread: click to view message previewRe: Tiny incompatibility between DOM Core Level 2 and DOM Core Level 3The WG discussed this topic on the 11 Feb 2004 conference call according to bug 525 (http://www.w3.org/Bugs/Public/show_bug.cgi? id=525). Those with access to the member archives should be able to find the minutes and see what actions were voted on. The following search shows other discussions involving INVALID_CHARACTER_ERR on www-dom that may pertain to the issue: http://www.w3.org/Search/Mail/Public/search? keywords=INVALID_CHARACTER_ERR&hdr-1-name=subject&hdr-1-query=&index- grp=Public__FULL&index-type=t&type-index=www-dom
Web Hosting Reviews from OSDir.com Sister Site iBizWebHosting.com
|
|
