XQuery’s burden of high level of required knowledge use which consists of its complex operational use, and required knowledge of XML and its hierarchical structure have not gone unnoticed at the academic research level. Projects have already been launched projects to enable XQuery to perform schema-free access and processing. This enables XQuery to query XML data automatically and efficiently without requiring precise knowledge of the document structure. This action helps establish that there is a need for a more advanced automatic navigationless processing of XML and there is some movement to offer solutions that move the industry in this direction. The academic community working on XQuery has decided that the solution to schema-free XQuery processing is through the external addition of Lowest Common Ancestor (LCA) procedural function support. This is currently being utilized internally and automatically in our SQL hierarchical prototype. This processing is not being utilized currently by standard XQuery. The XQuery LCA academic research solution has had some success introducing LCA processing onto XQuery through the introduction of an external LCA XQuery function usually placed on the WHERE operation. From the experience with our SQL hierarchical prototype which transparently performs the LCA logic internally as needed, we have seen that there are more than one use for LCA’s and these uses require different logic to be applied to each use. There is the WHERE clause use and the SELECT operation use covered previously each concerned with proper ancestor range. So there should be more than one type of LCA function and its use. The SQL SELECT operation also allows easy control over which data is desired. This type of operation needs to be supported by a dynamic output formatting capability that is still missing in XQuery. SQLfX supports this automatic output formatting. More importantly, SQLfX has demonstrated that the LCA process can be needed in many locations which is made more complicated by the number of paths accessed and the location of the data types. This requires nesting of many different LCAs. External solutions may not succeed. Nesting of LCA functions may not be possible; this will limit the complexity of the multipath query possible. In addition, the specifying of the LCA function is not transparent; it will still require its use by an XQuery professional. In fact, it will require a professional who is also knowledgeable of these more complicated LCA processing and programming issues. The use of the LCA function can also affect the way the XQuery query is coded requiring a different design strategy that may be much less efficient. SQLfX's processing is limited to database (data centric structured data) data and ignores the processing of Markup (document centric semistructured data) data in order to obtain the most power and accuracy for SQL’s processing of XML’s structured data. But it should be pointed out that XQuery research is not limiting its access to database (structured) data and is also processing markup (semistructured) data. This means it has to process duplicate named node types common in markup which means LCA node types are no longer fixed and their location can dynamically change their position. This is necessary for markup searching where the results can be fuzzy by continually reducing the meaningfulness of search results until a match is found. This complicates the LCA determination logic for markup processing and means that structured data advantages can not be taken advantage of.