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: 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