On Sunday, July 29, 2001, at 07:02 PM, Scott Sanders wrote:
> Bring it on!
the way that matching rules work at the moment are a concern to me.
(maybe i don't understand then well enough - or maybe they need enhancing.
i'm going to write as if i understand them but i'm sure you'll set me
right where i don't)
the current way that matching rules work means that the number of rules
required rises almost exponentially for complex schema.
you can only wildcard prefixes (*/a but not a/*). this means that you end
up having a rule for every child for a parent that adds child in a certain
way. for example, you end up adding the same rule for */a/b, */a/c and */a/
d since you can't wildcard a suffix and say that any child element of a
follows this rule. i'd say that you can get round this problem by adding
support for a single level suffix (.../a/?) which would match all child
elements (eg. match a/b, a/c and a/d). this suffix wildcard can be
combined with the prefix wildcard (eg. */a/?).
i can see why the longest matching key-pattern is a good rule for small
schemas, but i think that it results in too many rules for complex schema.
for example, you'll often want the same creation rule where-ever an
element appears. the longest matching key-pattern system means that you
need to code an additional copy of the creation rule for each occasion
that the element is found in a longer key-match. i'd say that you can get
round this problem by having a special universal class of matching
key-sets which cannot be overridden by the longest matching rule.
if you think these enhancements are worthwhile, then i'm willing to submit
patches.
- robert
