Menu
▾
▴
exist-development
|
From: Tony R. <to...@go...> - 2010-04-08 01:15:43
|
Hi eXist devs, My name is Tony. I was going through the eXist website and thought that I would offer my services to improve the documentation. Specifically, I do pretty well with: improving spelling, grammar, punctuation, typography, and phrasing (for clarity) (Also, I can only do this in English—sorry! I love languages in general, but I don’t know any well enough to do any real proofreading tweaks outside of English.) working with X/HTML and CSS I’ve been informed there’s a new site in the works, but if anyone working on the new site is looking for an extra hand I am totally willing! Before I start working, I had a few questions about the documentation. I’m just going to fire off a list of questions from the top of my head, and feel free to answer just one or two if you want. (Of course, if you don’t mind answering more, that’d be great, too!) And now…the questions: I noticed that documents using DocBook are not updated to DocBook5. How come? Would it break anything if I started converting everything to DocBook5? Many files appear to be custom XML vocabularies. Are these vocabularies documented anywhere? In past experiences, I’ve found documentation pretty easy to track down. But in eXist, with practically everything being based on XML—and no obvious directories like “doc/“—I am a little apprehensive. Is there a particular part of the documentation I should work on first? Any other requests for a newbie like me? :) Thanks a lot for helping make such a fantastic tool for XML junkies! eXist is a pretty fantastic piece of software! :) —Tony | “Zearin” |
|
From: Adam R. <ad...@ex...> - 2010-04-08 08:39:34
|
> My name is Tony. I was going through the eXist website and thought that I
> would offer my services to improve the documentation.
Hi Tony, that sounds excellent :-)
> (Also, I can only do this in English—sorry! I love languages in general,
> but I don’t know any well enough to do any real proofreading tweaks outside
> of English.)
Documentation is only made available in English at present, so no problem there.
> working with X/HTML and CSS
>
> I’ve been informed there’s a new site in the works, but if anyone working on
> the new site is looking for an extra hand I am totally willing!
Interesting, can I ask where you heard this?
> I noticed that documents using DocBook are not updated to DocBook5. How
> come?
>
> Would it break anything if I started converting everything to DocBook5?
Not sure to be honest, we use some XSLT to convert the DocBook into a
layout for the site. I guess the XSLT may need to be updated as well,
do you know XSLT?
> Many files appear to be custom XML vocabularies. Are these vocabularies
> documented anywhere?
Can you give me an example of which files do you refer to?
> In past experiences, I’ve found documentation pretty easy to track down.
> But in eXist, with practically everything being based on XML—and no obvious
> directories like “doc/“—I am a little apprehensive.
True, perhaps the documentation should be moved under
$EXIST_HOME/webapp/documentation and reorganised into sensible
sub-folders.
> Is there a particular part of the documentation I should work on first?
Nothing springs to my mind, perhaps you have seen something ;-)
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Wolfgang M. <wol...@ex...> - 2010-04-08 09:09:02
|
>> I’ve been informed there’s a new site in the works, but if anyone working on >> the new site is looking for an extra hand I am totally willing! > > Interesting, can I ask where you heard this? I already had a chat with Anthony yesterday evening and asked him to write an introduction to this list. It is no secret that we paid a designer from existing funds to work through our site. We made several attempts to do this ourselves in the past, but we never got anywhere (I'm a lousy designer). Anyway, it doesn't make much sense to invest time into rewriting the CSS and XSLT before we have the redesigned templates. >> I noticed that documents using DocBook are not updated to DocBook5. How >> come? >> >> Would it break anything if I started converting everything to DocBook5? The main stylesheet we use is webapp/stylesheets/db2xhtml.xsl. It would be nice to convert this, though we would also need to switch all the documentation and the search function to use namespaces. Layout changes can still be done later. Well, Loren is the documentation coordinator, so we have to ask if a migration to docbook5 would be feasible now? >> Many files appear to be custom XML vocabularies. Are these vocabularies >> documented anywhere? Some files, e.g. the main index.xml, use old stylesheets/vocabularies and should probably be converted to docbook as well. > True, perhaps the documentation should be moved under > $EXIST_HOME/webapp/documentation and reorganised into sensible > sub-folders. I agree. Wolfgang |
|
From: Leif-Jöran O. <lj...@ex...> - 2010-04-08 09:50:18
Attachments:
smime.p7s
|
Den 2010-04-08 11:08, Wolfgang Meier skrev: >> True, perhaps the documentation should be moved under >> $EXIST_HOME/webapp/documentation and reorganised into sensible >> sub-folders. > > I agree. Well, I am not that happy with having the documentation under webapp. I would like it to be copied there on installation if one wishes instead or in same step as it is installed into the database. Loren you, as the documentation coordinator, probably already have some ideas here? Leif-Jöran |
|
From: Loren C. <lor...@gm...> - 2010-04-08 11:44:45
|
On Apr 8, 2010, at 04:50 AM, Leif-Jöran Olsson wrote: > Den 2010-04-08 11:08, Wolfgang Meier skrev: > >>> True, perhaps the documentation should be moved under >>> $EXIST_HOME/webapp/documentation and reorganised into sensible >>> sub-folders. >> >> I agree. > > Well, I am not that happy with having the documentation under webapp. I > would like it to be copied there on installation if one wishes instead > or in same step as it is installed into the database. > > Loren you, as the documentation coordinator, probably already have some > ideas here? > Yes. I am working on an idea for the documentation to be loaded into the database from one of eXist's servers. That way the documentation will have any corrections since the release was created. We would have copies for each release so that the installer would grab the appropriate documentation. Installing the documentation into the DB also allows the documentation to be searchable. Loren |
|
From: Loren C. <lor...@gm...> - 2010-04-08 11:39:03
|
Hello Tony, We welcome the help. Would you like me to schedule a conference call? We can talk about ideas. On Apr 7, 2010, at 08:00 PM, Tony Rogers wrote: > Hi eXist devs, > > > My name is Tony. I was going through the eXist website and thought that I would offer my services to improve the documentation. > > > Specifically, I do pretty well with: > > improving spelling, grammar, punctuation, typography, and phrasing (for clarity) > (Also, I can only do this in English—sorry! I love languages in general, but I don’t know any well enough to do any real proofreading tweaks outside of English.) > working with X/HTML and CSS > I’ve been informed there’s a new site in the works, but if anyone working on the new site is looking for an extra hand I am totally willing! > > Before I start working, I had a few questions about the documentation. I’m just going to fire off a list of questions from the top of my head, and feel free to answer just one or two if you want. (Of course, if you don’t mind answering more, that’d be great, too!) > > > And now…the questions: > > I noticed that documents using DocBook are not updated to DocBook5. How come? > Would it break anything if I started converting everything to DocBook5? I am planning on converting to DocBook5, but am waiting for the new design before tackling the conversion of the db2xhtml.xsl file. We can also develop a style guide so that the eXist documentation is consistent in the organization and presentation. > Many files appear to be custom XML vocabularies. Are these vocabularies documented anywhere? > In past experiences, I’ve found documentation pretty easy to track down. But in eXist, with practically everything being based on XML—and no obvious directories like “doc/“—I am a little apprehensive. An idea that I have been toying with would be to have the documentation downloaded into the database during installation. Th\at way, then documentation is always up to date and it would be searchable. > Is there a particular part of the documentation I should work on first? > Any other requests for a newbie like me? :) > > Thanks a lot for helping make such a fantastic tool for XML junkies! eXist is a pretty fantastic piece of software! :) > > > —Tony | “Zearin” > Again. Welcome to the party :) Loren |
|
From: Dan M. <dan...@gm...> - 2010-04-09 16:04:09
|
Hello Tony, Sorry for the delay in getting back to you. We really welcome any help documenting the eXist system, especially for beginners. > Also, I thought that XSLT was by design better suited to transform what is essentially the same document from one format to another, while XQuery is preferable for grabbing subsets of data—for example, a bug database. I think the second statement is true. XQuery is perfect for quickly getting the titles from a large collection of indexed XML documents. But the first is somewhat debatable. My experience is that I can teach people how to do an XQuery typeswitch tranforms in about an hour or two. Most people prefer the syntax of XQuery over XSLT. In my opinion the only reason to write in XSLT is if you must do the transforms in a browser. There are no other valid reason any more to continue to use XSLT. I say this after spending three years doing mostly XSLT and attempting to train others. My work teaching XQuery is that it is much easier to learn. Especially by people that have SQL or PHP experience. In our case with the eXist documentation project we may have 1000 DocBook documents in the future and we frequently want to get list of the documents and perform searches in the database of keywords. So they will all be indexed in the system anyway. We are now working on converting all the XSLT programs to XQuery for our tools. I would be happy to send you the source if you are interested, but it will need to be cleaned up and documented. Here are the first examples: http://www.syntactica.com/rest/db/org/syntactica/apps/docbook/views/list-items.xq I still need to get the source code to format like the eXist documents. - Dan On Thu, Apr 8, 2010 at 9:37 AM, Tony Rogers <to...@go...> wrote: > On Apr 8, 2010, at 9:59 AM, Dan McCreary wrote: > > Hello Tony! > > Welcome to the team! > > I am working on an XQuery script that will convert DocBook 5 to XHTML. > > Here is the start of two new beginner's guides: > > > http://www.syntactica.com/rest/db/org/syntactica/apps/docbook/views/list-items.xq > > Let me know if you are interested in helping. The conversion is being done > with a typeswitch transform<http://en.wikibooks.org/wiki/XQuery/Typeswitch_Tranformations> > . > > - Dan > > > > Oh, I’m interested in helping anything that deals with outputting XHTML & > CSS. :) > > I admit I have VERY little experience with XQuery. I’ve basically just > played around with it now and again in oXygen. I am much more experienced > with XSLT 2. > > Also, I thought that XSL was by design better suited to transform what is > essentially the same document from one format to another, while XQuery is > preferable for grabbing subsets of data—for example, a bug database. > > I’m totally interested in helping, even if you have your heart set on > XQuery! I just wanted to ask about the choice to use it over XSL for a > conversion. :) > > (BTW let me know what I can do. I may be inexperienced with XQuery but I > know there is a much shorter distance from reading it to understanding what > it does compared with XSL. I think I’ll still be able to contribute > something or other that might be useful.) > > —Tony > -- Dan McCreary Semantic Solutions Architect syntactica.com 952-460-1674 VOIP: 111@69.199.167.229 |
|
From: Tony R. <to...@go...> - 2010-04-09 17:48:05
|
Hey Dan!
On Apr 9, 2010, at 11:57 AM, Dan McCreary wrote:
> Hello Tony,
>
> Sorry for the delay in getting back to you. We really welcome any
> help documenting the eXist system, especially for beginners.
>
> > Also, I thought that XSLT was by design better suited to transform
> what is essentially the same document from one format to another,
> while XQuery is preferable for grabbing subsets of data—for example, a
> bug database.
>
> I think the second statement is true. XQuery is perfect for quickly
> getting the titles from a large collection of indexed XML documents.
> But the first is somewhat debatable. My experience is that I can
> teach people how to do an XQuery typeswitch tranforms in about an hour
> or two. Most people prefer the syntax of XQuery over XSLT. In my
> opinion the only reason to write in XSLT is if you must do the
> transforms in a browser. There are no other valid reason any more to
> continue to use XSLT. I say this after spending three years doing
> mostly XSLT and attempting to train others. My work teaching XQuery
> is that it is much easier to learn. Especially by people that have
> SQL or PHP experience.
>
> < … >
Oh, no problem. Although, it makes me sad to hear that XSLT is out of
favor now. I began learning XSL using Saxon (with XSLT 2.0) and
invested plenty of time into it. I also found it a delightfully strange
and beautiful way to transform data. Sad to see it fade. :(
There was one statement you made that has me curious:
> There are no other valid reason any more to continue to use XSLT.
What did you mean by “any more”? Specifically:
* So it used to be preferred, but no longer?
* What caused this change?
* Does this include XSLT 2.0? (I completely skipped XSLT 1.0 and
learned on 2.0. But I have heard that 2.0 made life worlds easier.)
…
I’m just curious—I’m *not* trying to debate anything, or trying to get
you to switch, etc! :)
Just trying to understand the evolution of the tools and the evolution
of how people use those tools.
—Tony
|
|
From: Tony | \Zearin\ <ze...@us...> - 2010-04-09 18:02:23
|
Hey Dan!
On Apr 9, 2010, at 11:57 AM, Dan McCreary wrote:
> Hello Tony,
>
> Sorry for the delay in getting back to you. We really welcome any
> help documenting the eXist system, especially for beginners.
>
> > Also, I thought that XSLT was by design better suited to transform
> what is essentially the same document from one format to another,
> while XQuery is preferable for grabbing subsets of data—for example, a
> bug database.
>
> I think the second statement is true. XQuery is perfect for quickly
> getting the titles from a large collection of indexed XML documents.
> But the first is somewhat debatable. My experience is that I can
> teach people how to do an XQuery typeswitch tranforms in about an hour
> or two. Most people prefer the syntax of XQuery over XSLT. In my
> opinion the only reason to write in XSLT is if you must do the
> transforms in a browser. There are no other valid reason any more to
> continue to use XSLT. I say this after spending three years doing
> mostly XSLT and attempting to train others. My work teaching XQuery
> is that it is much easier to learn. Especially by people that have
> SQL or PHP experience.
>
> < … >
Oh, no problem. Although, it makes me sad to hear that XSLT is out of
favor now. I began learning XSL using Saxon (with XSLT 2.0) and
invested plenty of time into it. I also found it a delightfully strange
and beautiful way to transform data. Sad to see it fade. :(
There was one statement you made that has me curious:
> There are no other valid reason any more to continue to use XSLT.
What did you mean by “any more”? Specifically:
* So it used to be preferred, but no longer?
* What caused this change?
* Does this include XSLT 2.0? (I completely skipped XSLT 1.0 and
learned on 2.0. But I have heard that 2.0 made life worlds easier.)
…
I’m just curious—I’m *not* trying to debate anything, or trying to get
you to switch, etc! :)
Just trying to understand the evolution of the tools and the evolution
of how people use those tools.
—Tony
|
|
From: Adam R. <ad...@ex...> - 2010-04-09 19:44:35
|
> I think the second statement is true. XQuery is perfect for quickly getting
> the titles from a large collection of indexed XML documents. But the first
> is somewhat debatable.
I would argue that XSLT is much better suited to transformations than
XQuery. I think both XSLT and XQuery have their place and should be
used when appropriate like any tool. They both have their strengths
and weaknesses and together they are an excellent package.
> My experience is that I can teach people how to do
> an XQuery typeswitch tranforms in about an hour or two. Most people prefer
> the syntax of XQuery over XSLT.
In my experience the opposite is true, it is much easier to teach some
basic XSLT than XQuery, the templating approach is very natural and
non-programmer types feel much safer writting XSLT as an XML
vocabulary than they do XQuery code. I would also argue that IDE's
with the Schema for XSLT make it much easier to see problems in the
code as you are writting in than with XQuery.
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Wolfgang M. <wol...@ex...> - 2010-04-09 18:03:55
|
Hi Dan, so you suggest to migrate our current stylesheets to XQuery? I don't really mind since the stylesheets will need to be revised anyway, but it should be discussed first. We should probably choose the approach which is easier to cope with for most people. Personally, I sometimes prefer XSLT for simple, top-down transformation processes, but well, we may not need to force beginners to learn both, XSLT and XQuery at the same time. Wolfgang |
|
From: Joe W. <jo...@gm...> - 2010-04-09 18:34:21
|
Hi Wolfgang, Tony, Martin, Dan, Even though I learned XSLT first before XQuery, I find it much easier to maintain XQuery than XSLT stylesheets, since that's what I work in 100% of the time now. I converted a TEI-to-XHTML stylesheet from XSLT (65 templates) to XQuery (41 functions, including the master typeswitch) routine. I am now much happier than before, when I'd have to "relearn" XSLT any time I wanted to make a change. One "valid" reason to use XSLT, of course, would be if you want to use an existing stylesheet or framework out of the box. For example, the TEI Consortium maintains an incredible array of XSLT stylesheets, for TEI to XHTML, XSL-FO, docx, LaTeX, slideshows, etc.; I imagine DocBook does something similar. But if you really want to really customize your output and you are going to substantially rewrite the stylesheet anyway, I agree with Dan that there are real benefits to moving to an all-XQuery workflow. Another question that has been raised is the DocBook 4 to 5 transition. I'm not familiar with DocBook, but given the benefits of DocBook 5 and using XQuery for transformation, how disruptive would it be to do *both* at once? (1) Convert the eXist documentation to DocBook 5, and (2) convert the stylesheet from DocBook 4-oriented XSLT to DocBook 5-oriented XQuery? Another factor to consider is that I count 23 XSL files in the "stylesheets" directory. Should all of these be converted, or only "db2xhtml.xsl"? If not all 23 need to be converted, which are the key ones? Joe On Fri, Apr 9, 2010 at 2:03 PM, Wolfgang Meier <wol...@ex...> wrote: > Hi Dan, > > so you suggest to migrate our current stylesheets to XQuery? I don't > really mind since the stylesheets will need to be revised anyway, but > it should be discussed first. We should probably choose the approach > which is easier to cope with for most people. > > Personally, I sometimes prefer XSLT for simple, top-down > transformation processes, but well, we may not need to force beginners > to learn both, XSLT and XQuery at the same time. > > Wolfgang > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > |
|
From: Loren C. <lor...@gm...> - 2010-04-09 19:55:07
|
I think that we should be converting over to DocBook 5. We can keep the current 67 documents where they are until we have the new style for the documentation developed and implemented. We should be developing new documentation using DocBook 5 and developing an organization of the information and a style guide to create a standardized "look and feel" to the documentation. Consistency makes things easier to read. The current documentation would then be converted into the new format manually. The current documentation can be converted from 4 to 5 and then the contents can be manually entered into the new system. I like the use of XQuery for the presentation. If we store the sections as separate files then we can use the Physical Divisions capability of DocBook http://www.docbook.org/tdg5/en/html/ch02.html#ch02-physdiv to assemble them. We can avoid some of the redundancy in the documents: On installation of eXist, the sections can be loaded (as an installation option) into the database under some collection like /system/docbook or /system/doc. Once the system is up and running, then there would be an administrative task to go find updates on the http://demo.exist-db.org server and download the updates. With this approach, we can also have an option that extracts all of the contents under a section into a book and then run XSL FO (on demand) to create a PDF, eBook, etc. On Apr 9, 2010, at 01:33 PM, Joe Wicentowski wrote: > Hi Wolfgang, Tony, Martin, Dan, > > Even though I learned XSLT first before XQuery, I find it much easier > to maintain XQuery than XSLT stylesheets, since that's what I work in > 100% of the time now. I converted a TEI-to-XHTML stylesheet from XSLT > (65 templates) to XQuery (41 functions, including the master > typeswitch) routine. I am now much happier than before, when I'd have > to "relearn" XSLT any time I wanted to make a change. > > One "valid" reason to use XSLT, of course, would be if you want to use > an existing stylesheet or framework out of the box. For example, the > TEI Consortium maintains an incredible array of XSLT stylesheets, for > TEI to XHTML, XSL-FO, docx, LaTeX, slideshows, etc.; I imagine DocBook > does something similar. But if you really want to really customize > your output and you are going to substantially rewrite the stylesheet > anyway, I agree with Dan that there are real benefits to moving to an > all-XQuery workflow. > > Another question that has been raised is the DocBook 4 to 5 > transition. I'm not familiar with DocBook, but given the benefits of > DocBook 5 and using XQuery for transformation, how disruptive would it > be to do *both* at once? (1) Convert the eXist documentation to > DocBook 5, and (2) convert the stylesheet from DocBook 4-oriented XSLT > to DocBook 5-oriented XQuery? > > Another factor to consider is that I count 23 XSL files in the > "stylesheets" directory. Should all of these be converted, or only > "db2xhtml.xsl"? If not all 23 need to be converted, which are the key > ones? > > Joe > > > On Fri, Apr 9, 2010 at 2:03 PM, Wolfgang Meier <wol...@ex...> wrote: >> Hi Dan, >> >> so you suggest to migrate our current stylesheets to XQuery? I don't >> really mind since the stylesheets will need to be revised anyway, but >> it should be discussed first. We should probably choose the approach >> which is easier to cope with for most people. >> >> Personally, I sometimes prefer XSLT for simple, top-down >> transformation processes, but well, we may not need to force beginners >> to learn both, XSLT and XQuery at the same time. >> >> Wolfgang >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Exist-development mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-development >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development |
|
From: Wolfgang M. <wol...@ex...> - 2010-04-09 20:43:02
|
Hi Joe, > Even though I learned XSLT first before XQuery, I find it much easier > to maintain XQuery than XSLT stylesheets, since that's what I work in > 100% of the time now. I converted a TEI-to-XHTML stylesheet from XSLT > (65 templates) to XQuery (41 functions, including the master > typeswitch) routine. This is interesting to hear and confirms Dan's observations with which I tend to agree (though I enjoy writing XSLT as well, but I probably have enough training in it). > Another question that has been raised is the DocBook 4 to 5 > transition. I'm not familiar with DocBook, but given the benefits of > DocBook 5 and using XQuery for transformation, how disruptive would it > be to do *both* at once? (1) Convert the eXist documentation to > DocBook 5, and (2) convert the stylesheet from DocBook 4-oriented XSLT > to DocBook 5-oriented XQuery? This will not be a major effort. Most of the documentation only uses a subset of docbook which should be easy to convert (maybe even automatically, using an XSL?). > Another factor to consider is that I count 23 XSL files in the > "stylesheets" directory. Should all of these be converted, or only > "db2xhtml.xsl"? If not all 23 need to be converted, which are the key > ones? db2xhtml.xsl is the only important one. It is used by nearly all pages on the website. The others are either old (left over from Cocoon) or only used for a single purpose (roadmap.xsl). One or two documents (index.xml) are still using an old stylesheet (doc2html.xsl) and need to be migrated to docbook. Wolfgang |
|
From: Adam R. <ad...@ex...> - 2010-04-09 19:46:42
|
> so you suggest to migrate our current stylesheets to XQuery? I don't > really mind since the stylesheets will need to be revised anyway, but > it should be discussed first. We should probably choose the approach > which is easier to cope with for most people. I dont think that doing basic document to document conversion in XQuery makes any sense, XSLT is easier to develop this in and more intuitive. If you wanted to start doing some processing and business logic as well during the conversion then sure use XQuery. But for simple conversion XSLT is much easier. > Personally, I sometimes prefer XSLT for simple, top-down > transformation processes, but well, we may not need to force beginners > to learn both, XSLT and XQuery at the same time. Sure. The XSLT user base out there is much larger than the XQuery user base in my opinion, I think even most novice XQuery users are likely to have had some exposure to XSLT. > Wolfgang > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Wolfgang M. <wol...@ex...> - 2010-04-09 20:30:38
|
> I dont think that doing basic document to document conversion in > XQuery makes any sense, XSLT is easier to develop this in and more > intuitive. I think this is a misunderstanding. A simple document to document transformation can sometimes be even more intuitive in XQuery ;-) All you need to learn is typeswitch plus a few function calls. I'm using this more and more in my own code (for example, see http://exist.svn.sourceforge.net/viewvc/exist/trunk/eXist/webapp/biblio/jquery.xql?revision=11607&view=markup). Done in the right way, the control flow in an XQuery can be easier to understand and maintain than the template matching mechanism of XSLT. Don't misunderstand me. I like XSLT. I use a pretty large XSLT to generate multi-volume, 1000 pages PDFs from a set of TEI documents stored in eXist. The processing only takes a few minutes, despite the thousands of small queries it sends to eXist, e.g. to assemble bibliographies and SVG graphics. However, this also shows the limitations of XSLT: it becomes quite tricky once you need to integrate data from many sources. Native XSLT support in eXist would overcome this limit. It's on the way, but there's still a lot of work left to be done. Anyway, my main argument for using more XQuery for the website is that you want to keep the examples as simple as possible and reduce the number of standards new users have to learn. Wolfgang |
|
From: Thomas W. <tho...@gm...> - 2010-04-11 13:37:23
|
Tony, Asking about what is better XQuery or XSLT is like asking which car is better Ferrari or Bentley. The answer is: "It depends"! What are you looking for, how are going to use it, who are you going to use it with etc. To me XSLT and XQuery in the XML world are like the left and the right hand - some tasks are better, quicker and easier to reach when implemented with XSLT and other are better, quicker and esier when written in XQuery. There is never a simple "right" answer. Are you are writing one off transformation? How often you are going to change it and the most important question - which of these languages comes more natural to you and makes you more productive. I used to write almost everything in XSLT using XQiery just as a glue layer between the requests, the database and the XSLT. Recently because of time constraints I switched to XQuery completely and I am very pleased with the quick results. I still use XSLT here and there and I am convinced XSLT is a place to lay very good foundations for XQuery. I think one of strengths of XSLT is its simple mechanism for extensibility when using pattern matching. All you need to do is to add an include file with additional pattens and you are done. You can repeat this as many times as you need without ever changing the original XSLT file. You can even generate a list of include files as you need them, even in run time. XSLT is perfect for creating highly reusable libraries. Using the typeswitch in XQuery is completely the opposite. The only way to extend the original functionality is to add MANUALLY all new cases into the ORIGINAL file. When we work with predictable, stable, slow changing data, like documentation XQuery it perfectly OK. But if you do data driven applications there the code adapts to the data then XQuery is still behind XSLT. Having said that I have to add that using util:function and util:call can find same way around and mimic the XSLT way. My point is the extensibility in XQuery does not come out of the box as with XSLT. Switching same functionality from one language to another could be very educational and brings a lot of fun. If somebody wants to toy with it and there is a need I say why not, go for it. There is always room to make things better, faster and easier to maintain. I hope this helps. Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 On 9 April 2010 21:30, Wolfgang Meier <wol...@ex...> wrote: > > I dont think that doing basic document to document conversion in > > XQuery makes any sense, XSLT is easier to develop this in and more > > intuitive. > > I think this is a misunderstanding. A simple document to document > transformation can sometimes be even more intuitive in XQuery ;-) All > you need to learn is typeswitch plus a few function calls. I'm using > this more and more in my own code (for example, see > > http://exist.svn.sourceforge.net/viewvc/exist/trunk/eXist/webapp/biblio/jquery.xql?revision=11607&view=markup > ). > Done in the right way, the control flow in an XQuery can be easier to > understand and maintain than the template matching mechanism of XSLT. > > Don't misunderstand me. I like XSLT. I use a pretty large XSLT to > generate multi-volume, 1000 pages PDFs from a set of TEI documents > stored in eXist. The processing only takes a few minutes, despite the > thousands of small queries it sends to eXist, e.g. to assemble > bibliographies and SVG graphics. However, this also shows the > limitations of XSLT: it becomes quite tricky once you need to > integrate data from many sources. Native XSLT support in eXist would > overcome this limit. It's on the way, but there's still a lot of work > left to be done. > > Anyway, my main argument for using more XQuery for the website is that > you want to keep the examples as simple as possible and reduce the > number of standards new users have to learn. > > Wolfgang > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X