Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Build applications using the "simplicity stack"
 Arjun, thank you very much for these details about your perspective! There are two things I have not yet understood well: the strong distinction between XPath and what is beyond, and the insistence to get "out" of XML. First, you seem to distinguish strictly between XPath from XQuery, appreciating the first but not very interested in the second. I look at things differently. Not only is XQuery formally a superset of XPath, but also in practise I never perceive a real distinction. Yes, XPath, this model of navigation, is like the heartbeat of XML technology, the very core whose importance cannot be overemphasized: any XML technology is built on top of XPath. But XPath is not the material from which to build systems: (a) it cannot construct (can only extract); (b) it cannot create complexity. And both issues are answered brilliantly by XQuery, by (a) its constructor expressions and (b) its FLWOR
expression, as well as (c) the structural features of user-defined functions and library modules. Therefore I regard XQuery as *the* universal XML processing language. (This is not to say that in many scenarios XSLT has not advantages; but it is less universal because more biased towards transformation, a character emphasized by the fact that the output of XSLT is either a document or text - not an XDM value.) The second detail that puzzled me was your phrase: " ... is good enough as long as it gets my data _out_ of XML.:-) " In my experience it is usually very easy to turn XML into something else, but often rather laborious the other way around. As long as stored in XML, the information is, so to speak, charged with potential energy which I can unleash in order to transform, evaluate, extract etc. So it is, as a rule of thumb, advantageous to bring information into XML as soon as possible, and to "leave" that state in the last possible moment. As coincidence has it, tomorrow I will have to do some extra work because in some processing I
had left XML one step too early. I should have assembled the information content of some required non-XML as XML and only in the last moment perform a mere change of representation, rather than leave XML and still perform logic after that. Now further processing is necessary, and the non-XML representation is nothing I can work with, the logic went into it but cannot be extracted again out of it. The non-XML representation is final and not fit to be used as intermediary. A sink, a final point, a trap. XML is the perpetual intermediary. Kind regards, Hans-J��n Arjun Ray <arjun.ray@verizon.net> schrieb am 12:08 Donnerstag, 3.April 2014: On Thu, 03 Apr 2014 09:35:06 +0100 (BST), Hans-Juergen Rennau <hrennau@yahoo.de> wrote: | Did you sufficiently take into consideration that XML-encoded | information is addressable, down to the smallest item, in a | unified way which could not be more concise and at the same time | more intuitive? Minus the idiocy of "XML namespaces", I have nothing against Xpath. In fact, I'd say that xpath-based processing has been the key to whatever success can be claimed for XML. Not only were there other nifty ideas where Xpath came from, but the ways to use Xpaths may not have been exhausted yet. | I think that to speak about the "usefulness" of XML forgetting | the existence of these technologies makes little sense, Xquery is often closer to what I need than XSLT; but generally, anything Xpath-aware _and_ scriptable (which includes purpose-built utilities of my own devising) is good enough as long as it gets my data _out_ of XML.:-) | Little example. You have two XML files and you are interested in the | differences. Ah, yes.:-) As it happens, this was one of the use cases, years ago, that led me to go against my better judgment and address a W3C Working Group with a suggestion, as a (publicly invited) comment on a draft: http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/2000Feb/0005.html Despite an endorsement by someone whose opinion might have counted, http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/2000Mar/0005.html (See also: http://www.w3.org/2000/08/lb2/) the "idea" elicited no response at all, neither yea nor nay, from the olympian worthies of the Working Group. As I had expected all along, the www-xml-canonicalization-comments list was the official place to be ignored. But I wasn't blameless: maybe that was karma, as they say. I let the credit be given to me because, at the time, I thought that revealing the source would have killed the proposal stone dead at once, anyway. (Anyone who knows where Xpath came from would know where this "handy line-breaking algorithm" came from.) | Can you give me examples of how this could be achieved equally easily | after leaving XML format? I'm a big fan of "low-tech" solutions. Given the choice between some Xquery-capable gizmo and plain old diff to get some one-off job done, I prefer the situation where the latter is available. _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
