[Bug 8238] Add support for X3D

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238





--- Comment #4 from Maciej Stachowiak <mjs@apple.com>  2009-11-08 15:03:18 ---
(In reply to comment #3)
> (In reply to comment #2)
> > It would be helpful to convert this bug report to a more specific request.
> 
> Maciej, can you explain what you perceive to be missing?

The original bug report consisted of the summary "Add support for X3D", linked
to the X3D spec, and included a list of elements and attributes. Maybe I'm
lacking context, but that did not seem very specific. What counts as "support"?

> Meanwhile, I'll restate the request as follows: the request is for embedded X3D
> grammars to be parsed into the DOM in a way that matches what is produced when
> the same grammar is included in XHTML.

That's much more specific. Thank you.

Some comments on your proposed alternatives:

> 
> As background, the current spec causes the parser to go into a different mode
> when an element whose name matches "math" or "svg" is encountered.  This
> affects the namespace of the associated and nested elements, causes trailing
> solidus characters in start element tag syntax to be interpreted as void
> elements, and causes a number of element and attribute names to be fixed up to
> be mixed case.  Doing the same for X3D would address this request.

Tentatively, I would not be in favor of an X3D-specific mechanism in the
parser. X3D is not supported directly by UAs, and it's not clear if it ever
will be (since there are competing 3D model serializations with similar or
greater levels of traction). It should also be noted that purely script-based
solutions can fix up the parsing just as easily as they can implement the
rendering.

With my browser implementor hat on, implementing a significant extra parsing
complexity in browsers solely for a single feature that will only be
implemented by script- or plugin-based add-ons does not seem like a good
tradeoff.

> 
> The referenced email describes an alternate approach which would work for all
> elements but the "i18n" element in X3D.  It would not recover properly from
> cases where a non-well-formed X3D fragment is included in a larger document
> which consists of HTML elements in ALL CAPS (something that is conforming, but
> increasingly rare), but at least all conforming HTML5 parsers would recover
> consistently.

If I understand correctly, the root element of X3D is not mixed case ("X3D"
only has capital letters), so it doesn't seem like the email proposal satisfies
your request. Interesting idea though.

[Side note: I may be misunderstanding the X3D spec here, but the spec doesn't
seem to state a namespace URI for X3D, and  none of the examples have a default
namespace declaration on the root element. Is X3D actually in a namespace?]


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 8 November 2009 15:03:33 UTC