[plt-scheme] Re: matching XML types

Benderjg2:
> One difference though is the semantics of pattern matching for attributes:
> with PLT's match, if you give a pattern like (@ (attr1 ,v1) (attr2 ,v2)),
> both attr1 and attr2 must be present in the element being matched--and you
> can't give a default value (that I know of) if they are absent. As well,
> these can be the *only* attributes on that element. I allow pattern matching
> of attributes where the selected attributes must be either present in the
> element or be "defaulted"-- and the element may include other attributes.

Not really.  One uses a second matcher on the attribute list if one doesn't
want to constrain which attributes must be present or the order in which
they must appear.  A major problem that I have when using XML
transformations written in the currently popular languages (eg XSLT) is that
they are normally written in too general a manner and often result in
unforseen "collatoral damage" when used on real data.

Actually, this is one case where I think it's possible to draw a distinction
in the roles of attributes and elements.  Where the order, presence, etc of
data attached to the current tag is not important, attributes are useful. 
The match ability to "hide" the entire attribute list behind one match
variable is useful here.

> link? will match (link "... contents ..."). It will not match something
> constructed with a:link or b:link-- which would produce a locally named
> element (from a:link) or an element in a different namespace (from
> b:link).

I think this makes sense.  I do wonder how we're going to cope when we're
using the second or third version of some XML syntax.  In places where this
is already happening (eg RSS), it's quite a mess at the moment.
-- 
MJR