[x3d-public] X3D file conformance philosophy
andreasplesch at gmail.com
Wed Sep 23 10:54:58 PDT 2015
Using the x3d validator and quality assurance tools which come with
x3d-edit, it will become quickly apparent that an x3d file is deemed
conforming (or syntactically correct) only after it passes a series of very
strict tests which are defined here:
For example, referencing a field of a node which is not listed in the spec.
but is supported by a x3d browser (say "id") will put the x3d file in the
unconforming category. Is this correct ?
Similarly, referencing nodes and behaviours which are not explicitly
defined in the spec. will break conformance.
This is in contrast to the concept of validity of html files which are
deemed valid even if they include elements not defined in the spec.
So, what is the philosophy of having a narrow definition of file
It may be that it defines minimum functionality for a x3d browser.
A x3d browser is said to be conforming when it allows browsing of a
conforming file as a minimum requirement.
But this convention would still apply if a conforming file could include
custom (non-spec.) nodes and fields which a conforming browser would be
allowed to ignore.
Another way to think about the usefulness of strict conformance may be to
explore the consequences of restricting tests for conformance only to
nodes, fields, behaviours and such with which the spec. is actually
concerned. What would break if ignoring all other elements in browsers and
parsers would be considered conforming ?
In my view, a strict view of file conformance shifts responsibility from
the browser to the x3d content author. To me, this is a somewhat inverted
view which may need to be reconsidered.
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the x3d-public