|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Why not reinventing the wheel ?
Hi Eric, > I enjoy XSLT a lot, but if some brilliant guys think they can define a > language that is better fitted for some purposes why should I worry > --even if there is a huge overlap ? If you just make the definition of your universe at hand sufficiently narrow, anyone can claim that their particular solution is the best for the job. If every working group at W3C used this method to justify new syntaxes, however brillant they would be, it would soon get very messy. I think that there's definitely a need for XQuery, however, it's problem domain is not peculiar enough to justify a completely new syntax. And I don't think this marketing plot with case-insensitive keywords is enough to make the SQL-people come running into the XML world. > Some competition between may be a good motivation and I would rather > regret that XSLT has been lacking credible competitors and alternatives > for such a long time. > > I see competition as simulating and source of diversity and richness (if > it's true for schemas, why not for XSLT? ). > If XSLT/XPath and XQuery were developed by competeting companies, or even if one was under W3C and the other under ISO, this would have been a natural thing. And I agree that some competition can be fruitful. However, I'd like to think that *consistency* is an important issue for W3C. Do you mean this is not of importance in this case? > If people had not always being trying to reinvent the wheel our cars > would roll on logs... I think looking for new, unifying and better syntaxes is important, but I think it should be done as a separate effort. Also, a new and brilliant syntax doesn't have to be incompatible with the old one. It would have been much better if XQuery had taken an evolutionary path rather than restarting from scratch. My criticism is partial here though, since much has been borrowed from XPath which is good. By evolutionary I mean this: XSLT and XQuery share a common pattern: 1) select nodes 2) generate the result tree In XSLT the first is handled by XPath and the second by template instructions. An evolutionary approach had been to extend, and subset (for optimization purposes) each of these to get a comprehensive and yet optimizable solution. As I said, XQuery does do this with XPath (modulo namespace handling and case-insensitive keywords), but for the generative part nothing is reused. Strange. About terseness: building XQuery on XSLT/XPath doesn't necessarily require you to specify a full stylesheet for each query. Just as there are simplified constructs in both XSLT and XPath there could be in XQuery: A simple query could be just <xquery select="a"/> If you needed to order the result, bring in some more power, <xsl:for-each select="person" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:sort select="name"/> <xsl:copy-of select="."/> </xsl:for-each> And so on. Well, let's hope all this gets settled down in the XML mapping :-) Cheers, </David>
|
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
|
|||||||||

Cart








