[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)
>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. In other words, any program that handles TREX patterns is required to deal with elements context-sensitively, even if the program merely replaces <p> with <para> (or <danraku> in Japanese). Can a simple XSLT stylesheet implement such renaming? >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 tend to think that no restrictions are easier to understand for users. On the other hand, I tend to think that tight restrictions are easier to understand for users. Cheers, Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC