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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK: RELAX NG and DocBook


Here's something else RELAX NG-related that might interest a lot of
people on this list. But it's not directly relevant to DocBook, so if
don't care much about RELAX NG, don't bother reading...

If you're already accustomed to DTD syntax but have needed to read or
write schemas expressed in verbose-and-harder-to-read XML syntax and
found it a chore, it may make you happy to know that James Clark has
designed a more concise and more readable "shorthand" non-XML syntax
that lets you define RELAX NG patterns minus all the angle brackets
and closing tags and using some of the same familiar shorthand
regex-like symbols that are used in DTDs. Here are a few examples of
how the non-XML RELAX NG syntax maps to the XML syntax:

           RELAX NG XML syntax                RELAX NG non-XML syntax        
  =======================================  ============================
  <choice> p1 p2 </choice>                  p1 | p2               
  <group> p1 p2 </group>                    p1 , p2               
  <interleave> p1 p2 </interleave>          p1 & p2               
  <zeroOrMore> p </zeroOrMore>              p*                    
  <oneOrMore> p </oneOrMore>                p+                    
  <optional> p </optional>                  p?                    
  <element name="_QName_"> p </element>     element _QName_ { p }
  <define name="_identifierNotKeyword_"
    combine="choice"> p </define>           _identifierNotKeyword_ |= p

And he's built a tool to convert instances of the non-XML syntax to
valid RELAX NG XML syntax:

  http://www.thaiopensource.com/relaxng/nonxml/

That all allows you to write this kind of a RELAX NG pattern
definition:

  combine = attribute combine { "choice" | "interleave" }

instead of needing to write all this:

  <define name="combine">
    <attribute name="combine">
      <choice>
        <value>choice</value>
        <value>interleave</value>
      </choice>
    </attribute>
  </define>

Basically, it often lets take a take a pattern that you'd need maybe 5
or 6 lines to define in XML syntax and define it in 1 line instead --
making the pattern definition a lot more readable.

The main practical limitation I know of with using the non-XML syntax
is that there's no way for it to represent annotations -- so if you
use it, you can't specify default values for attributes. Otherwise, I
think anything that can be expressed in real RELAX NG XML syntax can
be expressed in the non-XML syntax.

And before some wise guy says, "Great, he's reinvented DTD syntax!",
maybe it's worth pointing out that when you write something in this
non-XML syntax, I guess you could say you're now "thinking" in terms
of RELAX NG grammars, where for example, elements and attributes (and
some of the functional equivalents of parameter entities) are defined
in exactly the same way.

If you were to write something in DTD syntax before converting it to
RELAX NG, you'd not be thinking in terms of RELAX NG grammars, but
still in DTD-think, where for example, attributes and all parameter
entities are defined and referred to in a different way than elements.

I personally prefer RELAX NG-think to DTD-think. Maybe the differences
seem subtle, but I guess most evolutionary differences do.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC