I’m inclined to agree with Mark on this one, though you’re raising some salient points. XForms itself is a mess with regards to namespace - in addition to the xf namespace you have a separate namespace for events and another for schemas, and this is even before you get to a stage where you are dealing with out of band integration. If you assume, as I do, that at least from a browser standpoint the purpose of a namespace is to act as a key for a look-up table of libraries, then so long as the enveloping namespace - in this case, the XHTML 2.0 ns, maps the appropriate sub-bindings into the language and integrates the libraries - then the fact that the xforms namespace isn’t explicitly declared becomes moot.

The one aspect where I think the caveats should be raised is that this should in essence be a line in the sand kind of decision, and not be made to apply retroactively. That is to say, at this stage it would be dangerous and foolhardy to institute a chameleon rule for XHTML1.0, given that this specification is already frozen and forming part of the infrastructure. It seems rational to me to assume that if you have some nsXHTML2 namespace, the provision for chameleoning would have to be explicitly built into the schema, and perhaps would require that all chameleoned namespaces would have to be explicitly declared (I’m still going through the proposal on this, so just making guesses at this stage). This also raises a second tacit assumption that any collisions in namespaces that occurred would have to be fully qualified - for instance, if both XHTML and XForms had a switch statement, you would have to explicitly declare xf:switch as a child.

To go back to your previous analogy, I see such chameleons as being a critical piece in better integration of modular units. As it stands now, an XHTML 1.0 document increasingly looks like a Victorian house that’s been added to over the years by different builders - with siding on one part of the house, stone on a second and wood on a third. Chameleoning would at least make it a little easier to state “Here is a new wing of the house, but it needs to be sided with wood of a certain shade in order to keep it looking out of place.” As someone who’s had to fight dealing with four or five different namespaces in XForms documents, I can say that I’d certainly welcome the ability to “hide” them.

Add to this that the number of namespaces are increasing at a faster rate than the number of Specifications, this increase being fueled in part by the need of most organizations to use XML Schema, and to use it in an efficient maintainable manner, which basically requires increasing the number of namespaces.

But I don’t think chameleon schemas are a big problem, if, as I understand it, the namespace of xforms in XHTML will always be the XHTML namespace. That said it is annoyingly stupid. It seems to be predicated on increasing productivity so that poor markup writers won’t have to write xf: when what it will probably do is decrease productivity because of having to port solutions for namespace x to namespace x+ all the time.

The big problem for XSL-T, DOM, any namespace processing application is the existence of xsi:type.
Luckily every application I’ve ever seen just assumes that xsi:type doesn’t exist. Some day someone will use that to cause problems I bet.

Now, why do it this way rather than just include the namespaced XForms schema, I don’t know.

- Jasen.

Let’s be clear: chameleon schemas are not required to allow languages to incorporate XForms functionality directly. There is no reason I can see that a language such as VoiceXML or XHTML 2 cannot simply add the XForms schema by reference, while keeping those elements in their own namespace. That is a completely reasonable and plausible option. Why has this been rejected?

If you see a straw man here, please explain to me how what I’ve set up differs from what the XHTML2 and XForms working groups are actually doing. It was not my intent to set up a straw man argument. This is my understanding of what’s actually going on based on reading the specs and communications from various working group members. If the XForms working group is not planning to use different namespaces for XForms in different host languages (and specifically in XHTML 2) then please say so, and explain what they’re actually trying to accomplish with section 2.2.1 of the XForms spec, because if it’s not this I can’t figure out what it is.

The reason you are finding it so easy to ’save the world’ from this “insanity” is that you have set up a strawman…and by definition strawmen are pretty easy to defeat. However, in this case you’ve not understood what it is you are railing against.

The reason for the chameleon namespace schemas is to allow languages to incoporate XForms functionality directly. Say for example, the VoiceXML group wanted to re-use the XForms data model, but they wanted it to be part of their language. They could do this by make the XForms model and instance elements part of VoiceXML, and the chameleon schemas allow them to do this easily.

XHTML 2 is doing this; it still defines an input control in the same way that HTML does, but it says that the functionality or definition of this control comes from XForms. This is good re-use in my book, and doesn’t necessarily require that the control is prefixed with xf:.

Regards,

Mark

Mark Birbeck
CEO, x-port.net

http://skimstone.x-port.net/