Re: [x3d-contributors] LC-150: XML Schema Language Last Call Issue Response: Array Sizes

Frank Olken wrote:
>                                         October 13, 2000
> [...]
> Additional Points
> -----------------
> [...]
> Apropos Don Brutzman remarks - see Henry Thompson's response
> cited above on the merits of markup vs whitespace separation.
> (
> http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000OctDec/0015.html
> )
> 
> Brutzman's proposal to use regular expression to express
> the structured array datatypes encoded as attribute values
> can probably be made to work.  Most of the members of the
> Schema WG would view such a development with unalloyed horror,
> as an inappropriate use of regular expressions.

How horrifically appropriate for Friday 13th with a full moon!     :0

> I reiterate Henry's remarks that failure to mark up individual
> array elements makes it very difficult to process individual
> array elements with XSLT or to reference them via XPATH.

This is a well-understood point.  Other considerations prevailed:

- consistent use of attributes to represent base-type data throughout
  the mapping of VRML 97 to XML
- tags for every base-type value greatly reduced scene readability and
  authorability, perhaps past any practical use by humans using
  text editors, because of tag clutter
- tags for array elements did not particularly improve processing 
  accessibility, because
- arrays of 3D field values (the VRML MF* multi-field base types) rarely 
  need to be accessed in isolation - changing a single MF-value usually
  implies knowledge & manipulation of the entire array of values
- arrays of VRML base types are not special cases but rather treated as
  base types themselves
- existence of alternate API (Scene Authoring Interface, or SAI) for
  methods to directly manipulate field values, e.g. setValue() and 
  set1Value() values
- use of SAI methods much more likely for high-performance time-critical
  3D applications
- accessing individual tuples within the array thus unlikely for XSLT
  or XPATH manipulation
- regular expressions can enable checking for any illegal characters,
  can enforce tupleness, and can even enable retention of VRML 97
  syntactic sugar which permits separating array elements by commas
  (we will decide later if we want or need to retain those commas)
- x3d-compromise.dtd was specifically chosen by group over an
  alternative tagset with such per-value tags
- no major problems (and very few minor problems) encountered while
  translating an extensive set of example scenes
- no other Total Cost of Ownership (TCO) problems noted

Example:  2 huge piles of polygonal vertices and normals drawing a bunny.
Modification of individual points to make rabbit ears wag smoothly will
probably occur by a series of authoring design choices like
- separate ear polygons from remainder of body
- consider simple scaling/rotation of that group (i.e. cheat), otherwise
- use native-VRML CoordinateInterpolator and NormalInterpolator nodes to 
  set the keyframe values corresponding to (beginning, (middle)*, end)
  array values
- trigger the interpolators, admire the cute bunny

Obviously more examples and some counterexamples exist.  Nevertheless
this is probably a representative example of the large-array attribute
case.  Hopefully the reasons above also illustrate why these design 
choices were made in the X3D DTD.

Perhaps similar reasons will exist for other languages that often include
very large chunks of numeric data.  Perhaps not.  Our tradeoffs are usually
dominated by 3D-specific run-time performance considerations.

Work on a draft X3D schema has finally begun - I've managed to reconfigure
IBM's Xeena editor to handle the recent revised Schema DTD drafts at
	http://www.w3.org/2000/10/XMLSchema.dtd
	http://www.w3.org/2000/10/datatypes.dtd

Hopefully an X3D schema will be working before the W3C AC meeting next 
month.    As mentioned before, we'll report back when there are implementation
results to report.  Assuming everything proceeds as planned, with or without
regex constraints working on MF-* array types, our likely response regarding
arrays is "LATER - VERSION 1.1."  Also as mentioned before, we are happy
to help on any forthcoming effort regarding arrays of complex types.

Again thanks for the excellent and fundamentally important work on Schema.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code UW/Br Root 200  work 831.656.2149
              Monterey California 93943-5000 USA              fax  831.656.3679
Virtual worlds/underwater robots/Internet     http://web.nps.navy.mil/~brutzman

Received on Friday, 13 October 2000 16:30:17 UTC