[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [relax-ng-comment] Abbreviated compact syntax (Re: Compact syntaxis not compact enough. Why?)
> > using a subtle roadsigns ( < and > ) to > > differentiate between <element> and 'reference' > > I don't want the difference between an element name and a reference to be > subtle. I want it to be blindingly obvious. Agree. YACC legacy tells that visual difference between 'TERMINAL' and 'nonterminal' *is* handy. > > RELAX NG addresses the same problem, using the > > word 'element' as a roadsign and I think it makes a > > mistake, because not a single preceding engine > > solves this ('referencing') problem with *that* > > kind of solution (introducing special keyword). > > Consider struct/union/enum in C. Or even Java: bare names are references; > the class keyword is followed by a class name and then the definition of the > class. Here you're talking about the 'declarations'. I see larger readability requirment in *usage*. (Just looking on something - being able to determine what is that 'something' is it 'terminal' ( element ) or 'non-terminal' - reference, or perhaps the 'keyword' - but that's optional ...). In DTDs (1) <!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | IMAGE | HIDDEN )"> <!ELEMENT INPUT - O EMPTY> <!ATTLIST INPUT TYPE %InputType TEXT NAME CDATA #IMPLIED VALUE CDATA #IMPLIED SRC %URI #IMPLIED CHECKED (CHECKED) #IMPLIED SIZE CDATA #IMPLIED MAXLENGTH NUMBER #IMPLIED ALIGN (top|middle|bottom) #IMPLIED %SDAPREF; "Input: " > > > If <element> is confusing, we may > > agree on some other roadsign ( like #for_example ) > > to differentiate between elements and non-elements. > > The problem is to find a roadsign that will be obvious to the uninitiated. > The "element" keyword does achieve this. If there was something that had > all the virtues of the "element" keyword while being terser, I would be all > for it. I have explained what I think the problems with <> are. OK. I still think that : 1. @attribute is 100% winner, because it builds on XSLT/XPath and from what I see in the real world, *any* developer (even the novice one) "already knows" that @ means 'attribute' ;-) 2. In my oppinion, David's <element> sends the 'right' message ( and it still looks like a winner to me ) However, if trying to find the "appropriate alternative to '<' from the past", I would go with 'terminal'. I mean that YACC allows TERM: 'something', but one can also use 'something' directly in the non-terminal expression. Considering the fact that elements are kinda 'terminals', one may write : 'library' { 'book' { @id { #text }, @available { #text }, 'isbn' { #text }, 'title' {@xml:lang {#text}, #text}, 'author' {@id {#text}, 'name' {#text}, 'born' {#text}, 'dead' {#text}?}*, 'character' {@id {#text}, 'name' {#text}, 'born' {#text}, 'qualification' {#text}}* } + } in this case, references would not be surounded by single quotes, so the resulting syntax would still enforce usage of entities over the "plain elements" and #keywords ( BTW ) > That doesn't solve the problem of recognizing in > > foo | bar | baz { ... } > > that foo is an element name rather than a reference. Requiring arbitrary > lookahead to disambiguate is bad not just for machines but for humans as > well. OK, agree. If what I said above is not OK, one can try building on DTD's legacy ( which may be a good thing, BTW ), using %reference for references ( and < * > for 'tricky element names' ) leaving 'simple element names "unquoted" like it is in DTDs > If you don't have roadsign in front of elements, then I think you > need to have a roadsign in front of references (e.g. $) I think % would be better ( DTDs legacy), but I have nothing against '$'. I'm just against 'element'. Today I've converted one DTD/XSD ( MS developer ) guy to look at RELAX NG ( I used the current example of RELAX NG compact syntax ). The reaction of that guy was pretty much telling, in my oppinion. He first said: "It is so nice! It is like it is in regular expressions!" Then I said : "Doesn't the 'element' word disturbs you?" His answer was "Of course! Those are regular expressions! The 'element' keyword looks useless!" For me - no matter what particular nonation from a bunch described above ( with <, with ' or with %) would be picked, if it would replace the words 'element' and 'attribute' with some special characters either around element names, or before the reference of wherever - I would be happy with the result. My basic desire is to get rid of verbose 'element' and 'attribute', bringing RELAX NG closer to regular expressions ( because I want to implement the XML binding, based on this view ;-) Also, I don't actually insist on keywords having a special character in front of them. It seems that they could be recognized by context with not too much lookaheads. ( I may be wrong here, but I think that 'keywords' are relatively minor ... In fact, if it would be possible to have that 'text' thing ( like PCDATA ) not cluttering the grammar with those '#' - I think that would be better ) Rgds.Paul. [1] http://www.utoronto.ca/webdocs/HTMLdocs/HTML_Spec/HTML2-15Jun95/html.dtd
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC