X3D - a case study in centralized extensibility

Note: the subject line is not a typo, I do mean centralized.

Background: X3D is being pursued as a standard, with the intent of 
encouraging ubiquitous implementations, and has a serialization which 
enables it to be included inline in XHTML.

For some it might be helpful to see an example, and for those, I can 
point people to the following example which works on nightly builds of 
two different browsers today and on three different operating systems:


For others, seeing the standard may help:


At this point, I'll ask people's indulgence.  I believe that there are 
limits to which one can have productive discussions on extensibility of 
any kind without concrete examples.  For the moment, I would ask that we 
not rat-hole on whether or not this particular example is viable, my 
premise is that HTML5 has already adopted wholesale two other 
vocabularies, and at some point it is reasonably plausible that there 
will be a third and a fourth.  Whether or not such makes it in time for 
HTML5 isn't the question I want to explore for the moment, instead I am 
interested in gaining confidence that that such would be possible, and 
whether or not there are small changes to the spec now that might enable 
such things in the future.

Just for brainstorming purposes, I'll mention an example of such a rule 
that would nearly completely suffice for X3D would be: if the parser 
ever hits an unknown element which is mixed case and contains an xmlns 
attribute, then the parser goes into a mode in which element and 
attribute names become case sensitive, and trailing slashes in start 
elements cause the element to be treated as a void element.  This mode 
continues until either an element which contains only lowercase 
characters is encountered, or until the original element is closed.

The reason I mention the "break out" rule above for lower case names is 
that all of the cases previously discussed for svg and mathml where we 
expect browsers will have to deal reasonably with broken markup are 
things that we need to concern ourselves with on any markup that 
intended to become ubiquitous.

But again, the above is just for brainstorming, and I welcome alternate 
proposals.  The key thing I am concerned about at this time is the 
statements made in the following section:


X3D is an example of non-vendor specific markup.  Even so, I will 
suggest that as long as we recommend that any kind of extensibility be 
only pursued using XML, then it is incumbent upon us to address the 
perceived deficiencies which has limited XHTML's adoption (e.g., 
draconian behavior, lack of support in IE).

For tracking purposes, I've opened the following bug:


- Sam Ruby

Received on Sunday, 8 November 2009 01:15:29 UTC