XML representation of regular expressions

[Scott Zuyderduyn]

Hi all,

I've started planning a software project that utilizes XML to store a lot of
different input from the user. Regular expressions comprise a portion of
this input. I could store a regex as a plain string ("^(\w+)\s+(\d+)$"),
but this assumes POSIX-style regular expressions, and the software
requirements can't neccessarily assume this. Has anyone ever created or
seen an XML spec of a regular expression? For example, something that would
result in:

<regex>
<startAnchor/>
<pattern type="word" minLength="1">
<capture label="Name"/>
</pattern>
<pattern type="whitespace" minLength="1"/>
<pattern type="number" minLength="1">
<capture label="Age"/>
</pattern>
<endAnchor/>
</regex>

Best regards,

Scott

[Stefan Ram]

sc******@hotmail.com (Scott Zuyderduyn) writes:

I could store a regex as a plain string ("^(\w+)\s+(\d+)$"),
but this assumes POSIX-style regular expressions, and the software
requirements can't neccessarily assume this.

This only assumes, that the regex is a string.
Non-POSIX-style regular expressions are strings as well,
or are there any non-string regular expressions?
If there are different regular-expression-languages
used, the languages needs to be stored with the regex:

<regex lang="POSIX" code="^(\w+)\s+(\d+)$" />

Parsing different kinds of regular expression languages
into an XML-tree might become a large effort, that should
be made only for good reasons.

[Stephan Michels]

Scott Zuyderduyn <sc******@hotmail.com> wrote:

I've started planning a software project that utilizes XML to store a lot of
different input from the user. Regular expressions comprise a portion of
this input. I could store a regex as a plain string ("^(\w+)\s+(\d+)$"),
but this assumes POSIX-style regular expressions, and the software
requirements can't neccessarily assume this. Has anyone ever created or
seen an XML spec of a regular expression? For example, something that would
result in:

<regex>
<startAnchor/>
<pattern type="word" minLength="1">
<capture label="Name"/>
</pattern>
<pattern type="whitespace" minLength="1"/>
<pattern type="number" minLength="1">
<capture label="Age"/>
</pattern>
<endAnchor/>
</regex>

I try currently some efforts in this direction, but more to
build a parser with uses regex like XML structures.

My approach uses a combination of a ELR(0) and a Tomita style parser.

Something like

<definition name="definition">
<sequence>
<element name="name"/>
<element name="ws"/>
<char value=":"/>
<element name="ws"/>
<element name="regex"/>
<element name="ws"/>
<char value=";"/>
</sequence>
</definition>

<definition name="name">
<sequence>
<cclass>
<cinterval><char value="A"/><char value="Z"/></cinterval>
<cinterval><char value="a"/><char value="z"/></cinterval>
</cclass>
<zero-or-more>
<cclass>
<cinterval><char value="A"/><char value="Z"/></cinterval>
<cinterval><char value="a"/><char value="z"/></cinterval>
<cinterval><char value="0"/><char value="9"/></cinterval>
<char value="_"/>
<char value="-"/>
</cclass>
</zero-or-more>
</sequence>
</definition>

If you're interested in than see http://chaperon.sourceforge.net/

Stephan Michels.

[Patrick TJ McPhee]

In article <32**************************@posting.google.com >,
Scott Zuyderduyn <sc******@hotmail.com> wrote:

% different input from the user. Regular expressions comprise a portion of
% this input. I could store a regex as a plain string ("^(\w+)\s+(\d+)$"),
% but this assumes POSIX-style regular expressions, and the software

Apropos of nothing at all, that's not a POSIX-style regular expression.

% requirements can't neccessarily assume this. Has anyone ever created or
% seen an XML spec of a regular expression?

Even the XML schemas spec resisted the temptation to do this, in favour
of a compact format.
--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Scott Zuyderduyn]

"Patrick TJ McPhee" <pt**@interlog.com> wrote in message
news:bp**********@news.eusc.inter.net...

In article <32**************************@posting.google.com >,
Scott Zuyderduyn <sc******@hotmail.com> wrote:

% different input from the user. Regular expressions comprise a portion of % this input. I could store a regex as a plain string ("^(\w+)\s+(\d+)$"), % but this assumes POSIX-style regular expressions, and the software

Apropos of nothing at all, that's not a POSIX-style regular expression.
Indeed - too much Perl for me.

% requirements can't neccessarily assume this. Has anyone ever created or
% seen an XML spec of a regular expression?

Even the XML schemas spec resisted the temptation to do this, in favour
of a compact format.
--

Yes, a compact form is pragmatic, but idealistically it's a departure I
would think. Shouldn't anything more than a simple data type really be
described in XML? And regular expressions can be so arcane, an XML based
representation might actually be more easily understood if it was done
properly. I can understand in the context of having reasonably compact XML
Schemas, but it's still a surprise to me that I couldn't find a "mainstream"
regex spec.

Regards,

Scott

[Patrick TJ McPhee]

In article <eoCtb.401422$6C4.268056@pd7tw1no>,
Scott Zuyderduyn <sc******@hotmail.com> wrote:

% "Patrick TJ McPhee" <pt**@interlog.com> wrote in message
% news:bp**********@news.eusc.inter.net...

% > Even the XML schemas spec resisted the temptation to do this, in favour
% > of a compact format.

% described in XML? And regular expressions can be so arcane, an XML based
% representation might actually be more easily understood if it was done
% properly. I can understand in the context of having reasonably compact XML
% Schemas, but it's still a surprise to me that I couldn't find a "mainstream"
% regex spec.

I'm not disagreeing with you. My feeling is that the schema working group
had no interest in creating a reasonably compact xml representation for
schemas, so my guess is that if they didn't take it on, nobody has. It may
be just a matter of time. It seems like there are a lot of people
expressing context-free grammars in XML.
--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Keith Davies]

On Sun, 16 Nov 2003 03:44:10 GMT, Scott Zuyderduyn <sc******@hotmail.com> wrote:

Yes, a compact form is pragmatic, but idealistically it's a departure I
would think. Shouldn't anything more than a simple data type really be
described in XML?
Not necessarily. I've read in books about SGML that the creators freely
acknowledge that SGML is not the best way to store all types of data.
Being able to drop to a more specific, non-SGML syntax is useful. The
same is probably true of XML.

For instance, in some software I'm working on for an RPG, we need to be
able to represent random die rolls. It is possible to break it down to
something like

<roll>
<diecount>2</diecount>
<diesize>8</diesize>
<modifier>-2</modifier>
</roll>

but it makes much more sense to do

<roll expression='2d8-2' />

(or more likely, it'd be an attribute of whatever the roll applies to --
<damage roll='2d8-2' />)

I'm not a purist when it comes to XML; I think the amount of effort
needed to understand and use something should be proportional to the
importance of the individual components.
And regular expressions can be so arcane, an XML based
representation might actually be more easily understood if it was done
properly.

That's the rub. It wouldn't be easy. IMO, an RE is most easily
understood if you can *see* the thing. Counting parentheses isn't a big
deal. A complex RE (say, one that runs to one or two hundred
characters) would be a *nightmare* to try to read and understand if done
in XML -- at least, if each term had to be encoded in its own element.

That said, I can see ways to make things a little easier. You might use
allow an RE component to contain the 'arcane' parts but use XML elements
to link them together. For instance, an RE such as:

([A-Za-z]+|[0-9]+)

might be represented something like

<re var='var1'>
<choose>
<re>[A-Za-z]+</re>
<re>[0-9]+</re>
</choose>
</re>

This isn't *too* hideous. It is not nearly as concise as the first, and
mixes technologies. The latter is the bigger problem IMO.

Trying to fully-describe RE in XML would be horribly painful. Go ahead
and fall back on other representations for data where it makes sense;
this is one case.
Keith
--
Keith Davies "Your ability to bang your head against
ke**********@kjdavies.org reality in the hope that reality will
crack first is impressive, but futile"
-- Geoffrey Brent, rec.games.frp.dnd