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

Re: Parser/Parser generator in XSLT 3

  • From: yamahito <yamahito@gmail.com>
  • To: Andrew Sales <andrew@andrewsales.com>
  • Date: Sat, 23 Jun 2018 11:15:07 +0100

Re:  Parser/Parser generator in XSLT 3
Hi Andrew,

The DTD parser was (and still could be) for converting DTD to schematron, but I confess it’s mostly an exercise in honing my own XSLT skills ;)

On Sat, 23 Jun 2018 at 11:08 am, Andrew Sales <andrew@andrewsales.com> wrote:
Hi Tom, it's an interesting idea, but what is the driver for using XSLT to do this (not against, just curious)?

The SAX API callbacks provide access to DTD information, so tools such as DTDinst[1] and dtd2xml[2] produce an XML document containing that information. Entities are resolved by the parser.
Other similar tools may be available.

A transform can then consume such a document if it needs to.


On 23 June 2018 at 09:50, yamahito <yamahito@g...> wrote:

Hi Folks,

I find myself in need of an XSLT parser for DTDs for a side project I'm playing with; since my background isn't really in computer science, I lack the formal education on parsers, so I hope someone here can tell me if my thoughts make sense, or point me at some resources to fill in the gaps!

In the short term, I want to write a DTD parser; longer term, I think it would be interesting to make a parser generator.

There is a parser generator out there already that can create XSLT parsers from EBNF grammars (http://www.bottlecaps.de/rex/ by Gunther Rademacher), which seems very good: Jirka Kosek and Steven Pemberton have talked about using it at Balisage and XML London, e.g. to check validity on non-XML fragments using schematron.  I think there are two areas for improvement, however:

  1. The XSLT produced is a good example of functional programming; it uses functions that pass a state variable between them, etc.  However I wonder if there isn't a lot opportunity to make use of the underlying declarative paradigm of XSLT, particularly with the new data structures and abilities of XSLT 3.
  2. Because of the above, it's harder to extend the parser, e.g. by inclusion in another XSLT.  My use case for this is for a DTD parser which resolves entities.
As I understand it, most parsers include/depend upon a lexer, which tokenises the text, and then the parser builds the tokens into a hierarchy.  It does this by building a transition table that states, for a given context, which tokens can be validly expected to occur within.

It seems to me that a separate lexer and a transition table approach is trying to replicate functionality that's already in place in XSLT; what problems can people foresee with using modes and template matches rather than a transition table?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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.
First Name
Last Name
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.