Re: X3D - a case study in centralized extensibility

From: "Sam Ruby" <rubys@intertwingly.net>
Subject: X3D - a case study in centralized extensibility


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

Great!
>From what I saw, centralized for text/html means hard-coded into the 
html web browser.
For application/xhtml+xml it was less clear to me whether an entirely 
local already in the browser static content model is required.

> 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.
>

Right, X3D is an ISO standard with a fully specified W3C XML encoding 
which might enable it (or any adopted XML content model) to be used in 
HTML5 served in any flavor.

>
> 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:
>
> http://intertwingly.net/blog/2009/11/05/Web3D
>
> For others, seeing the standard may help:
>
> http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/X3D_XML.html
>
> 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.
>

At any point in time how can authors employ the latest and greatest in 
context of users accessing all the latest and greatest there ever was 
and will be?

>
> 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.
>

Fine. I worry about the actuallity of application/xhtml+xml browsers 
having to deal with broken markup. I would like to think that anything 
served as application/xhtml+xml or anything that referred to xml would 
be well-formed from the server.  That should be the author/publisher 
responsibility. Thus, when the web UA noticed structure problems it 
will know for sure it is some kind of error but could stop or skip 
over or try whatever. Maybe the sad fact is that by then an optimized 
downstream loader/runtime is probably already getting confused about 
what to do.

>
> 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:
>
>   http://dev.w3.org/html5/spec/Overview.html#extensibility
>
> 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).
>

A deficiency I see is that in the web browser UA whatever is 
downstream from the front end parser does not want to wait for its 
data so it says go ahead and send it, let me get on with it, and we'll 
figure out the closing tag stuff later. So, the author that serves 
malformed HTML is really still just guessing and depending upon 
browser makers following the HTML5 specification for text/html 
quirks/fixups/behaviors details.

>
> For tracking purposes, I've opened the following bug:
>
>   http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238
>

Thanks Sam, for offering this potential solution that deals with both 
case sensitivity and the HTML void element.

At the meeting, please excuse my misunderstanding of "void" elements. 
For some reason I had the understanding of "void" as the html case 
where the element markup
<... ...>
does not include the closing / and it is html OK (even required not to 
have it?), and what I was thinking of as "empty" element where the XML 
style
<... ... />
closing / is required to end the element markup.
Now I see the relationship of the void and empty terms actually 
relating to the same concept: No contained content; only attributes.

> For others, seeing the standard may help:

> http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/X3D_XML.html

Since you may be looking through the X3D XML encoding standard, please 
excuse me for including this Joe intro email guide to X3D. Here are a 
couple of my favorite links into various strong X3D information 
points:

Try the Element (Object) hierarchy diagram at:

http://www.web3d.org/x3d/specifications/ISO-IEC-19775-1.2-X3D-AbstractSpecification/Part01/concepts.html#f-Objecthierarchy

This shows text art of how the various concrete nodes derive from 
their abstract nodes. The abstract nodes serve to collect attributes 
that are common to all concrete nodes derived from them. Some concrete 
nodes derive from multiple abstract nodes. Abstract nodes (node names 
starting with X3D) never appear in the user code. The X3D XML schema 
has more abstract nodes than shown here to designate additional 
convenience content models.

Hint: in HTML it is either an element or an attribute; in X3D it is a 
field that can be either a node or an attribute.

At the top of the diagram the two branches show lists of variable 
types. X3D uses strong variable typing to simplifiy authoring 
including scripting. There are two lists side by side because X3D is 
optimized for handling arrays of values. For simplicity, everything 
starts out as a X3D field and these are called SF (Single Field) 
types.
For strings, the SFString type would look like
<... description='MyString' ...> where MyString is the content.
The MFString would appear as:
<... string="'MyS1', 'MyS2'" ...> where expected single/double quote 
nesting/escape/entities behavior is applied and the comma and/or space 
separator can be used to distinguish the two individual quoted content 
strings.

X3D also encodes numbers as SF or MF. For example, an SFVect3F has 
three numerical floating point components, representing x y z spacial 
coordinates. An SFVec3F value could look like:
<... location="0 0 10" ... />
and an MFVec3F value could appear as:
<... point="1 2 3, 4 5 6, 7 8 9" ... />
which would define three points in space

Please notice the SFNode and MFNode field types. I think of these as 
connections into the main diagram below which shows the name of each 
abstract and concrete node.

After that, take a look at:

http://www.web3d.org/x3d/specifications/ISO-IEC-19775-1.2-X3D-AbstractSpecification/Part01/nodeIndex.html

This is just the most convenient point to look at the definition of 
each of the abstract and concrete nodes.
In the X3D spec you need the Back key..

Now have a look at the examples shown at:

http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/examples.html

Now, since WebGL and the inventive X3DOM.org solution has collapsed 
the barrier of pluginless play for 3D in the WWW, most all of those 
examples will run straight up.

Also, there is the X3D wiki at:

http://www.web3d.org/x3d/wiki/index.php/Main_Page

Another resource I would like to offer to the group and all is:

http://www.hypermultimedia.com/x3d/Quick/NodesIDLIndex.htm

which is intended as a "quick" reference for X3D api.

>
> - Sam Ruby
>

Thanks to All and Best Regards,
Joe

Received on Sunday, 8 November 2009 21:20:49 UTC