Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Feasibility of "do all application coding in the XML

From: "James Fuller" <james.fuller.2007@-----.--->
To: "Christoph LANGE" <ch.lange@-----------------.-->
Date: 12/2/2008 11:54:00 AM
u might want to take another look at xquery  ... I have found that
most of the functional idioms are doable with extensions (1st class
funcs) and XQuery lends itself readily to working with XML... u may
even find you can port your code through time by directly using your
existing xslt transforms from within XQuery as you figure out
refactoring them.

I have a signifcant project using XQuery and it uses a generic fold
function as its main engine for 'doing stuff';  I think this choice in
architecture will eventually give me the opportunity  to use a
mapreduce algorithm to distribute processing ... well thats the
theory. Hopefully I will make a release of this app soon.

Getting the data structure right for defining rules in your app sounds
like the crux of the problem ... grammers, parsing etc ... all old
problems with solutions but still hard.

keep us updated on your progress, Jim Fuller

On Tue, Dec 2, 2008 at 11:47 AM, Christoph LANGE
<ch.lange@j...> wrote:
> On Tuesday 02 December 2008 11:03:04 Andrew Welch wrote:
>> Something to consider is Scala, which contains an xml type:
>>
>> http://www.scala-lang.org/node/131
>>
>> ...so you have both a general purpose language with an inbuilt xml
>> processing ability.
>
> I'm seriously considering a rewrite of my XML->RDF extraction library Krextor
> (http://kwarc.info/projects/krextor/) in Scala.  The internal XSLT
> implementation of the generic extraction algorithm that is independent from a
> particular XML input language and from a particular output RDF notation (be it
> text or XML) has become quite complex.  I would have liked to do parts of it
> in functional style and got used to FXSL, but due to some technical
> limitations (FXSL's implementation of currying), it didn't quite get as
> functional as I wanted it to be.
>
> On the other hand, I want to keep it easy for the users of my library (none so
> far, but some expected): They should be able to write easy patterns (e.g.
> XPath) that map XML elements or attributes to URIs of ontology concepts,
> whenever they implement a new extraction module for some XML language.
>
> Therefore, I need a language with XML built into the syntax.  Scala offers
> this, but its XML document model is quite limited, compared to DOM.  (Of
> course, it's more efficient instead, and DOM can be used with Scala, but not
> with nice syntactical support like pattern matching.)  E.g., I sometimes need
> patterns that traverse the parent or sibling axes, and for that, I'd need to
> take care of passing around such arguments myself.
>
> Cheers,
>
> Christoph
>
> --
> Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
>
>

_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent