OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng-comment message

[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