Lists Home |
Date Index |
There is a granularity of identity issue there. One does
not typically extract one face from an indexed face set
and use it elsewhere. Maybe the same can be said for a
line segment or a single coordinate. One can argue as
some will that meaningfulness is with the user and that
the format should enhance that to the maximum degree
possible. On the other hand, coordinates, for example,
are seldom atomic as meaningful units except to the
renderer unless one is working in a geo system of
map coordinates where coordinates are paired with
meaningful names (think intersection of two
highways). So in isolation, the decision to use
a number list makes sense. When one considers
reuse in a different semantic system, the case can
How theoretical is this? I don't know and maybe
it varies case by case, but it still seems odd to
me to have at least four XML languages with four
different dialects for coordinates.
We may wish to look at different combinations of
namespaces to see just how jangly the clash really
is. X3D and SVG are, IMO, obvious examples of
an opportunity to work together. CAD formats
(computer aided design) are another but are a
bit further into the future.
From: Simon St.Laurent [mailto:email@example.com]
If it's a wrapper format, fine. Call it a wrapper format. Don't sell
it as a new XML format.
This spec appears to be creating a whole new set of semi-random numbers
and letters, and calling it XML.
>Lists of numbers are common, BTW. X3D has them too.
>But when SVG and X3D finally do merge in a meaningful
>fashion, it will be painful to work in namespaces where
>each one has a different way to specify coordinates.
Even for people merely converting from one to another, never mind grand
unification, this creates huge problems. SVG does get criticized on a
semi-regular basis for this. Dunno about X3D, but it'd be a huge black
mark for me. Maybe they don't care - "it's just a delivery format" -
but I spend too much time extracting information from delivery formats
to take that claim seriously.