[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What niche is XQuery targeting?


inline schema problem
I'll add another essential benefit, somewhat related to (f):

(g) Just drop an XSLT 2.0 schema into an intelligent XML IDE and voilla --  
you have a syntax-oriented XSLT 2.0 editor with:
      - syntax colouring;
      - intellisense;
      - autocompletion;
      - expand/collapse trees;
      - meaningful error messages;
      - re-formatting and pretty-printing;
      - natural potential to add refactoring;

And you have this the same second you specify the schema!

Not just a theoretical meandring -- I have done this and other people have 
done this, too, see for example:

        http://norman.walsh.name/2004/07/25/xslt20

Cheers,

Dimitre Novatchev.

"Michael Kay" <mike@s...> wrote in message 
E1CbyBV-0007Wy-00@u...">news:E1CbyBV-0007Wy-00@u......
>> So Dave, we had this argument a couple of times, and I never
>> understood
>> your answer: what exact benefit do you get from the the fact
>> that XSLT is represented in it's current XML syntax ?
>
> I think the benefits are:
>
> (a) many stylesheets consist of two-thirds data to be copied into the 
> result
> tree, and one-third instructions to extract data from the source document.
> An XML-based syntax is beneficial for the two thirds that is data, because
> it means the code in the stylesheet is a template for the final result. 
> This
> also facilitates a development approach that starts with graphical 
> designers
> producing a mock-up of the target HTML or XSL-FO page, and then handing it
> over to a programmer to add the control logic. (XQuery has recognized this
> by using an XML-like syntax for element constructors, but there's a lot of
> difference between being XML-like and being XML.)
>
> (b) XSLT inherits all the lexical apparatus of XML: entities, character
> references, Unicode encoding, normalization of line endings and 
> whitespace,
> namespaces, base URI, and whatever the core WG dream up next. That means
> there's only one set of rules for users to learn; it means there's a lot
> less detail for the WG to reinvent and possibly get wrong; it means users
> can take advantage of XML editing tools; and it gives implementors a head
> start.
>
> (c) It's surprisingly common, especially in large applications, to see
> stylesheets being used as the input and/or output of a transformation. My
> favourite example is an online banking system that had 400 screens each
> generated by its own stylesheet, but all 400 stylesheets used a common
> look-and-feel which was achieved by generating them from a master database
> containing rules for all the different kinds of content that could be
> encountered. It's not obvious how one would do that in XQuery: one could 
> go
> some way with a function library, but not nearly as far (especially 
> without
> polymorphic functions). (And since queries aren't XML, I can't even search
> for all the queries that invoke a particular function, without a meta 
> query
> language!)
>
> (d) One of the original arguments was that for client-side applications,
> especially in small-footprint devices, only one parser would be needed
> rather than two. However, I've no idea whether this argument stands the 
> test
> of time.
>
> (e) XML vocabularies can be nested. We had no difficulty recently adding 
> the
> capability to have an inline schema within a stylesheet for describing its
> working data, because XSLT and XML Schema are both defined in XML. 
> Similarly
> stylesheets can be embedded in other XML documents, for example in the
> source document to which they apply, or in a pipeline processing language.
>
> (f) One unpredicted benefit, I think, is that the XSLT syntax ends up 
> being
> more systematic, extensible, and robust. It's much easier to add another
> attribute to an XSLT instruction than to extend the XQuery grammar, and 
> it's
> much easier for a compiler to catch all the syntax errors in one run.
>
> Historically, a lot of the motivation for XSLT being in XML was the
> experience of DSSSL, where the unfamiliar LISP-like syntax was widely
> regarded in retrospect as the reason for the lack of take-up. It was
> intended that XSLT should be writable by non-programmers, and I believe 
> that
> often happens. In fact I have heard it said that non-programmers have far
> fewer conceptual problems with the language than JavaScript or SQL
> programmers do.
>
>>
>> And why don't you get the same benefits from XQueryX (the pure XML
>> variant of XQuery) ?
>
> Because no one would ever want to author or edit or maintain a query using
> that particular language - it's far too low-level.
>
> Michael Kay
> http://www.saxonica.com/
>
>
> -----------------------------------------------------------------
> 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://www.oasis-open.org/mlmanage/index.php>
>
> 




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.