[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Proposed resolution for #19: attrInAttr
I have a similar concern with this. If the spec is going to say that implementations should issue a warning, it needs to define precisely what the condition is under which they should issue a warning. I don't think defining this precisely is trivial. You can have attribute patterns contains attribute or element patterns that can match something. For example, should it give a warning for: <attribute name="foo"> <choice> <data type="xsd:string"> <element name="bar">...</element> </choice> </attribute> ? Why should it not be an error to have something like: <attribute name="foo"> <element name="bar"/> </attribute> ? Is it because it is too hard to detect? If it's too hard to detect, then I don't want to say that implementations "should" detect it. ----- Original Message ----- From: "MURATA Makoto" <mura034@attglobal.net> To: <trex@lists.oasis-open.org> Sent: Friday, May 25, 2001 5:18 PM Subject: Proposed resolution for #19: attrInAttr > After studying GNF, I have changed my mind. Attribute patterns containing > attribute patterns look strange, but I do not see other technical reasons. > > Here is my proposal. > > This syntax allows attribute patterns to directly or indirectly contain > other attribute or element patterns, which never match anything. Implementations > SHOULD issue warning for such embedded patterns, but this is not an error. > > Cheers, > > ---- > MURATA Makoto mura034@attglobal.net > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC