Hi John,
My concern is more for SQL users who want to use XML as database data. They want correct results, they do not know XML, and they do not want XML centric access as their only choice. SQL business applications using SQL’s natural hierarchical processing are using unambiguous hierarchical structures where each node or data field can be unambiguously referenced. SQL’s navigationless access is maintained, XML becomes transparent. This also automatically produces a correct hierarchical result for business applications.
SQL still has the ability to easily rename nodes (tables in SQL) and attributes and element names (columns in SQL) to make the hierarchical structure unambiguous for database data hierarchical processing. Even IDref can be accommodated using SQL’s ability to dynamically create a duplicate node with a different name. So SQL hierarchical database processing does not require the elimination of duplicate types in XML, it can work with them using SQL’s current capabilities.
I would say the market for ANSI SQL transparent XML integration in SQL business applications and enterprise 2.0 user friendly interactivity would be quite significant. I do not believe the majority of SQL users are happy with the current SQL/XML industry where IBM, Oracle and Microsoft with the most of the market, all have proprietary and incompatible solutions and require significant knowledge of XML. This is OK for the hands on XML users, but not the majority of SQL non technical users. And ANSI SQL’s natural ability to perform fully hierarchically and correctly has shown that there is a ready made natural solution for the average non technical SQL user.
/Mike
-----Original Message-----
> The above description of LCA processing applies for standard
> hierarchical processing required for database data use. Duplicate
> database data types in the document should not be allowed. They should
> be renamed or always fully qualified. They can cause variable LCAs and
> database data should not allow this. This is OK for markup data, not
> database data. Just imagine performing an aggregation for record sales
> on “SALES” and a missing record data causes “SALES” of book sales to be
> added in. This is what you would want for markup use, but not database
> data use.
I find some of your ideas quite interesting, but I still haven't seen the
market demand them yet.I think the biggest problem with what you're saying is contained in the
paragraph above - XML users don't want to be constrained to not have
duplicate "database data types" as you call them, and they frequently
have element and attribute names that are the same but mean different
things in different documents and different parts of the same document.
John -- John Snelson, Oracle Corporation
http://snelson.org.uk/john Berkeley DB XML:
http://www.oracle.com/database/berkeley-db/xml XQilla:
http://xqilla.sourceforge.net