[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Restrictions on attribute patterns (attrInAttr)
James Clark wrote: > We can then describe the restriction on attributes as follows. It is an > error if the TREX pattern after transformation into normal form has an > "attribute" element with a descendant "ref" or "attribute" element. Kohsuke KAWAGUCHI wrote: > I don't see any reason to mandate this constraint check. I'd rather want > to see this check done by "lint" like program. There are two questions here. First, do we want a restriction on attributes? In other words, do we disallow patterns such that constraints on attributes contain constraints on elements? I am inclined to say "yes". Kawaguchi-san (and probably James), "no". Second, if we want a restriction, do we use the generalized BNF in the TREX specification? Or, do we want to rewrite the BNF? I would like to rewrite the BNF. But James does not. There are two relevant issues: (1) overlapping with XML Schema Part 2 and (2) constraints for disallowing <group><data type="..."/><data type="...."/></group> etc. If we would like to avoid overlapping with XML Schema Part 2, I would like to further rewrite the BNF. I would like to rewrite the BNF so as to disallow <group><data type="..."/><data type="...."/></group>. Kawaguchi-san and James have different checking algorithms, but I do not understand them yet. Cheers, Makoto Internet: mura034@attglobal.net Nifty: VEQ00625
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC