Odd syntax? xsl-fo 1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Odd syntax? xsl-fo 1.1

Dave Pawson-2
7.17.4 "text-decoration"

CSS2 Definition:
Value: none | [ [ underline | no-underline] || [ overline |
no-overline ] || [ line-through | no-line-through ] || [ blink |
no-blink ] ] | inherit


When converted (laboriously) to a schema definition...
It is long.
It is (to me) largely incomprehensible. I asked and received help from
the rng list.

There are a few examples of this...
I wonder
a) if xsd 1.1 can cope any better
b) this complexity is needed.
c) If it is needed, could it be simplified in some way

DaveP


<define name='textDecoration'>
  <attribute name='text-decoration'>
    <choice>
      <data type='token'>
        <param name='pattern'>(no-)?overline\s+((no-)?underline)?\s+((no-)?line-through)?\s+((no-)?blink)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>(no-)?overline\s+((no-)?underline)?\s+((no-)?blink)?\s+((no-)?line-through)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>(no-)?overline\s+((no-)?line-through)?\s+((no-)?underline)?\s+((no-)?blink)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>(no-)?overline\s+((no-)?line-through)?\s+((no-)?blink)?\s+((no-)?underline)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>(no-)?overline\s+((no-)?blink)?\s+((no-)?underline)?\s+((no-)?line-through)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>(no-)?overline\s+((no-)?blink)?\s+((no-)?line-through)?\s+((no-)?underline)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?underline)?\s+(no-)?overline\s+((no-)?line-through)?\s+((no-)?blink)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?underline)?\s+(no-)?overline\s+((no-)?blink)?\s+((no-)?line-through)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?underline)?\s+((no-)?line-through)?\s+(no-)?overline\s+((no-)?blink)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?underline)?\s+((no-)?line-through)?\s+((no-)?blink)?\s+(no-)?overline\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?underline)?\s+((no-)?blink)?\s+(no-)?overline\s+((no-)?line-through)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?underline)?\s+((no-)?blink)?\s+((no-)?line-through)?\s+(no-)?overline\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?line-through)?\s+(no-)?overline\s+((no-)?underline)?\s+((no-)?blink)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?line-through)?\s+(no-)?overline\s+((no-)?blink)?\s+((no-)?underline)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?line-through)?\s+((no-)?underline)?\s+(no-)?overline\s+((no-)?blink)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?line-through)?\s+((no-)?underline)?\s+((no-)?blink)?\s+(no-)?overline\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?line-through)?\s+((no-)?blink)?\s+(no-)?overline\s+((no-)?underline)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?line-through)?\s+((no-)?blink)?\s+((no-)?underline)?\s+(no-)?overline\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?blink)?\s+(no-)?overline\s+((no-)?underline)?\s+((no-)?line-through)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?blink)?\s+(no-)?overline\s+((no-)?line-through)?\s+((no-)?underline)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?blink)?\s+((no-)?underline)?\s+(no-)?overline\s+((no-)?line-through)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?blink)?\s+((no-)?underline)?\s+((no-)?line-through)?\s+(no-)?overline\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?blink)?\s+((no-)?line-through)?\s+(no-)?overline\s+((no-)?underline)?\s*</param>
      </data>
      <data type='token'>
        <param name='pattern'>((no-)?blink)?\s+((no-)?line-through)?\s+((no-)?underline)?\s+(no-)?overline\s*</param>
      </data>
    </choice>
  </attribute>
</define>


--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Reply | Threaded
Open this post in threaded view
|

Re: Odd syntax? xsl-fo 1.1

G. Ken Holman
At 2011-01-07 15:23 +0000, Dave Pawson wrote:

>7.17.4 "text-decoration"
>
>CSS2 Definition:
>Value:  none | [ [ underline | no-underline] || [ overline |
>no-overline ] || [ line-through | no-line-through ] || [ blink |
>no-blink ] ] | inherit
>
>
>When converted (laboriously) to a schema definition...
>It is long.
>It is (to me) largely incomprehensible.

That it is comprehensible by a schema processor is sufficient.  That
something that is required is awkward for the developer is irrelevant.

>I asked and received help from
>the rng list.
>
>There are a few examples of this...
>I wonder
>a) if xsd 1.1 can cope any better

Schematron assertion augmentations might be best I think, though I
haven't taken the time to draw it out.

>b) this complexity is needed.

It isn't complex.  To the user it is incredibly simple.  A set of
four mutually-exclusive pairs of values, or if not, one of two other values.

>c) If it is needed, could it be simplified in some way

Simplicity should be from the perspective of the user.  We
programmers have to take on the mantle of difficulty to make things
easy for the user.  I think making any decision to "simplify"
anything for technical reasons has to have zero impact on how the
user sees the issue.  If it impacts on how the user sees the issue,
it should be a non-starter.

We are here to serve our users.

If you technically simply that definition for the attribute, you will
change what it means to the user ... for example, if the technical
simplification allows, simultaneously, "none overline", the user is
poorly served by being allowed to enter something nonsensical.

The syntax is correct to meet the need, not "odd" ... the
implementation may need to be awkward to the developer to express
what the user needs.

I hope this helps.

. . . . . . . . . . . . Ken

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/f/
G. Ken Holman                 mailto:[hidden email]
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal