[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Issue: TREX elements appearing in foreign elements (Re: ATREX<documentation> element)
> To correctly skip foreign elements as well as their subordinate elements of the namespace > for TREX, we have to count the nest level. That is, whenever we encounter start or > end tags, we increment or decrement a counter. In order to know whether to give an error for a TREX element, you would also have to count the nesting level. > James Clark wrote: > >I don't see any need to treat TREX elements in foreign elements > >specially. They are ignored just like any other elements. It is very > >easy to implement this. > > What is very easy is a subjective issue. I think that most people do not > count the nest level, but merely create an event handler for elements of the > namespace of TREX. I've actually implemented TREX using a SAX interface. In my implementation, allowing TREX elements inside annotations does not require extra code; in fact disallowing TREX elements inside annoations would require extra code in my implementation. This is objective fact, not subjective opinion. Parsing TREX patterns requires you to deal with elements context-sensitively; elements are handled differently - within a grammar element - when expecting a pattern - when expecting a name class - within an anonymous datatype - when handling an empty element Whatever mechanisms the program uses for dealing with this context-sensitivity can also easily deal with ignoring TREX elements inside annotations. > >I can well imagine wanting an annotation that > >includes a TREX element. For example, I might want to have an > >annotation on a URI reference that gives a pattern for the referenced > >document. > > I understand that such annotations have some values. But I do not think > they do not belong to 80%. This is totally backwards. There is a distinction between (a) Complexity of the language as it appears to a user from the specification (b) Complexity of the implementation You are proposing increasing (a) in order to decrease (b). Unless the decrease in (b) is much larger than the increase in (a) that is a very bad tradeoff. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC