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

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

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


Subject: RE: [legalxml-econtracts] Another clause model proposal


Dear John,

Thanks for your comments. There are two key points at this stage.

1. Differences to Jason's proposal
The basic model is fairly much the same, except that Jason proposed adding a
List element and ListItem element. Jason also does not support the exception
to the new line behaviour of the Text element. I have also reverted to the
names of my original proposal. These issues were raised by the original
proposal from Jason and my alternatives.
Overall, the main point of the new document is the desire to provide a
fuller explanation of the issues for the TC to consider.

2. XHTML 2.0 draft
I asked one of our developers (Daniel Noll) to markup up the Attachment 1
example using the XHTML 2.0 model, as far as its known. Its set out below.
Without a proper DTD its hard to validate so there could be problems with
the example.

Daniel's quick comments are:

(a) In paragraphs, you can put <l> directly inside <p>, or omit the <l>. I
chose to put in the <l> in all cases here. The <l> acts very much like the
proposed Text element in the TC clause model. In XHTML 2.0 its possible for
people to mark things up either way, creating inconsistency in markup.

(b) XHTML 2.0 draft does not provide for the component or citation numbers.
The <x:num> elements are an extension I made up to fill the void.

(c) The model does not distinguish between a new paragraph after a list and
a continuation of the previous paragraph. See the end of 1.1 (e). Basically
this is because the list is not contained by the <p>.

(d) The model does not provide a way to contain all components of the
grammatical paragraph. The list is separated so it cannot be addressed and
manipulated as a discrete unit.

(e) The model retains the <ol> and <ul> which are redundant.

(f) The model does not as easily allow switching of content between the
document outline and the narrative content because it uses a different
elements in each.

(g) The XHTML 2.0 draft still contains H1 - 6 etc. It would be necessary to
implement a heavily cut down version of the schema.



<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE html ...>
<html>
<head>
<title>Markup example from Clause Model Requirements</title>
</head>
<body>
  <section>
    <x:num>1.</x:num>
    <h>Provisions about the specification of colours in contracts</h>
    <section>
      <x:num>1.1</x:num><h>Spectrum colours</h>
      <p><l>Here is a contrived, complex list structure using the spectrum
         colours and one or two others:</l></p>
      <ol>
        <li><x:num>(a)</x:num><l>red,</l></li>
        <li><x:num>(b)</x:num><l>orange,</l></li>
        <li><x:num>(c)</x:num><l>yellow,</l></li>
        <li><x:num>(d)</x:num><l>green,</l></li>
        <li><x:num>(e)</x:num><p><l>blue, including:</l></p>
          <ol>
            <li><x:num>(i)</x:num><l>pale blue,</l></li>
            <li><x:num>(ii)</x:num><l>dark blue,</l></li>
          </ol>
          <p><l>but excluding violet,</l></p>
        </li>
        <li><x:num>(f)</x:num><l>indigo, and</l></li>
        <li><x:num>(g)</x:num><l>violet,</l></li>
      </ol>
      <p><l>from which all colours can be derived.</l></p>
    </section>
    <section>
      <x:num>1.2</x:num><h>CMYK colours</h>
      <p><l>CMYK colours (cyan, magenta, yellow and black) are normally
specified for inputs to colour printing processes.</l></p>
    </section>
    <section>
      <x:num>1.3</x:num><h>RGB colours</h>
      <section>
        <x:num>1.3.1</x:num>
        <p><l>RGB colour (red, green, blue) specifications are used for
computer
              screen displays.</l></p>
      </section>
      <section>
        <x:num>1.3.2</x:num>
        <p><l>Using only these 3 colours, you can specify any
colour.</l></p>
      </section>
      <section>
        <x:num>1.3.3</x:num>
        <p><l>The Number of colours you can specify depends on the colour
depth available. For example:</l></p>
        <ol>
          <li><x:num>(a)</x:num><l>8 bit colour can render 256
colours;</l></li>
          <li><x:num>(b)</x:num><l>16 bit colour can render 65, 536
colours.</l></li>
        </ol>
      </section>
    </section>
    <section>
      <x:num>1.4</x:num><h>Using black and white</h>
      <section>
        <x:num>1.4.1</x:num>
        <h>Greyscale</h>
        <p><l>The Number of greys depends on the available colour depth, as
for other colours.</l></p>
      </section>
      <section>
        <x:num>1.4.2</x:num>
        <h>Black and white</h>
        <p><l>This is really called monochrome. You can specify
either:</l></p>
        <ol>
          <li><x:num>&#x2022;</x:num><l>black, or</l></li>
          <li><x:num>&#x2022;</x:num><l>white.</l></li>
        </ol>
      </section>
    </section>
  </section>
  <section>
    <x:num>2.</x:num><h>Colour profiles</h>
    <p><l>One thing to remember is that when working with colours, always
          use a colour profile that is available for your display or output
device. This will ensure you achieve the most consistent results.</l></p>
  </section>
</body>
</html>








>
>
> Hi Peter,
> Wow, very impressive document. I would like to understand better
> its differences
> from Jason's model, but my gut reaction is that you have proposed a most
> thoughtful clause model that I can support. I'm hopeful though that we can
> discuss tomorrow the news you kindly bring about XHTML 2.0 -- a
> draft I admit I
> have not been following. Maybe you could share your thoughts about these
> counter-arguments to your concerns about our adoption of XHTML
> 2.0 as the clause
> model, as you outline them in Section 6?
......



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