ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
[xml-dev] Integration By InfoSet Abstractions (WAS RE: [xml-dev] Out of top ic or out of interest?)
by Bullard, Claude L (Len) other posts by this author
May 3 2002 2:42PM messages near this date
[xml-dev] Experiment about resolving Accepted content header | [xml-dev] PDF 2 XML
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@[...].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.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved