Despite some warts, XML and the Web have done pretty well. They work and they work well. A large part of that is because both were designed with certain basic principles in mind. This gives them a unifying vision and a clean architecture that solves many problems.<\/p>\n
However, when a technology becomes successful it often attracts developers who recognize its success but don’t recognize or understand the underlying reasons for its success. Each one wants to make a change here, an addition there, a deletion somewhere else. Sometimes these suggestions are good and valid. Sometimes they’re not. However, even the suggestions that address real needs and use cases cause problems if they’re made without a deep understanding of the principles of the thing being changed. It’s like modifying a building by knocking down walls, cutting new windows, and erecting an extra bedroom on the roof. If you do this without consulting the original blueprints and understanding of the architectural principles that went into the house design, the best you can hope for is an ugly mess. More likely the whole structure will collapse around you, as the changes weaken the foundation the whole edifice rests upon. <\/p>\n
Previous examples include cookies, frames, SOAP, YAML, SimpleXML, binary XML, RSS, and many other cases I could mention. However the latest is coming from a place I really didn’t expect it: the W3C XForms and XHTML working groups. These two are working together to eviscerate XML namespaces, and make it difficult to impossible to process XHTML2 and XForms with standard XML tools like XSLT and DOM.
\n<\/p>\n
The problem is the notion of chameleon schemas<\/a><\/dfn>. These two working groups have decided to make it possible<\/a> to change the namespace of an XForm so that in one document it has the namespace http:\/\/www.w3.org\/2002\/xforms, in another it has the namespace http:\/\/www.w3.org\/2006\/xhtml2, and in a third it has the namespace http:\/\/www.example.com\/I\/cant\/believe\/theyre\/seriously\/considering\/this.<\/p>\n Because modern XML software identifies elements by local name and namespace URI, it will break every time an XForm is embedded in a a new namespace. Writing a generic XForm processors will become extremely difficult. I expect developers will begin looking at the local name and ignoring the qualified name, thus eliminating all benefits namespaces were supposed to have. Alternately they’ll just recognize a couple of namespaces (the default XForms namespace an the XHTML 2 namespace) and ignore all other possibilities. But even this will greatly complicate the code that implements the spec.<\/p>\n I honestly don’t understand why they want to do this. Perhaps the XHTML working group simply wants one less I have expressed my opposition<\/a> to this insanity with the working group. You may wish to do the same<\/a>. This is not how namespaces are designed to work, and it’s going to cause massive problems for anyone writing any sort of software to process XForms, whether it’s DOM, SAX. XSLT, XPath, or almost anything else. XForms elements should be able to be recognized by their namespace alone. You should not have to care about the host language in which they’re embedded. If we’re going to start changing the namespace for every host language that comes along, we might as well not have namespaces in the first place. <\/p>\n","protected":false},"excerpt":{"rendered":" Despite some warts, XML and the Web have done pretty well. They work and they work well. A large part of that is because both were designed with certain basic principles in mind. This gives them a unifying vision and a clean architecture that solves many problems. However, when a technology becomes successful it often […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[410],"class_list":["post-1000247","post","type-post","status-publish","format-standard","hentry","category-xml","tag-flash"],"_links":{"self":[{"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/posts\/1000247","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/comments?post=1000247"}],"version-history":[{"count":0,"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/posts\/1000247\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/media?parent=1000247"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/categories?post=1000247"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.elharo.com\/blog\/wp-json\/wp\/v2\/tags?post=1000247"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}xmlns:xf<\/code> attribute in each form-using XHTML 2 document? That hardly seems worth the trouble this will cause, but I haven’t been able to think of any other reason. <\/p>\n