OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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