[
Lists Home |
Date Index |
Thread Index
]
We went round and round this topic in the X3D project.
On one side, the XMLers wanted a DOM-based API. On the
VRML side, the implementors wanted a scene-graph API.
The DOM API, being generic, offered many opportunities
for the naive script developer to attempt illegal operations
on the scene graph API. So the counter that the DOM API
being well-learned and understood worked against the efficiency
of the product given that the implementor had to trap for
these operations and confuse the scripter. I suspect the
same can be true of other object-oriented applications.
Note that the conflicts over this issue lead many serious
and funded implementors to walk away from X3D. This is one
where the business case and the technical approaches were
conflated and are in conflict. Integration by infoset
abstraction is asserted to be a technical solution that
can by dint of heroic effort be made to work, but might
not produce a performant application, thus leveraging
the learning curve of XML may not be of value given
the market for real time 3D is sensitive to performance.
X3D itself is going forward and the results of the decisions
will be proven as they traditionally are when conflicting
philosophies of system architecture clash violently: in the
running code.
len
-----Original Message-----
From: Didier PH Martin [mailto:martind@netfolder.com]
I think we are witnesses of the clash between these two patterns. In case
(b) xml is not well integrated as a language type and (b) seems to be the
remedy (using function calls instead of data types) but with the conterpart
of not seeing the XML anymore (in addition to other secondary effects
already mentionned in this list). In case (a) we have direct contact with an
XML format but its underlying data structure is accessed as an external
entity not as a direct data type. Moreover, in (a) all semantics is lost in
the process since the procedural language is dealing with elements and
attributes instead of concrete objects like accounts, clients or whatever
expressed as variables. If anybody resolve the impedence mismatch in a
language like, for instance, in Java and provide access to the semantics
entities instead of the generic abstraction of the DOM maybe the average
developer would be more inclined to expreiment with integration through data
intead of integration through function calls.
|