RE: [legalxml-econtracts] Another clause model proposal

["Peter Meyer" <pmeyer@elkera.com.au>]

John,

Further comments inline below. The XHTML 2.0 draft development (only draft
5, not 6 as I had thought) gives us something to think about.

regards
Peter


>
>
> Peter,
> Thanks to you and to Daniel for the markup examples -- they're
> remarkable and
> illuminating for all of us. If you still have the patience and
> don't mind too
> much my pestering questions, there's a few more below.
> Contrasting your model to
> XHTML is quite helpful to me to better understand your proposal.
>
> >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.
>
> 	I'm not very bothered by the presence or absence of <I> or
> 	<Text> tags, given the behaviour of <xsl:value-of/>.  But your
> 	document states that the <Text> tag could be optional -- like
> 	the <l> tag, so I'm a bit confused by your point here. Overall,
> 	I am very happy with a tag like <Text> or <l> to represent text
> 	beginning with a new-line -- I really loathe <br/>...

The Text element would not be optional in the proposal. The document
proposes that, while its not necessary much of the time, it should be used
everywhere for consistency.
>
> >
> >(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.
>
> 	I think that the <label> element could be used here if necessary.
> 	At the same time, their draft spec says:
>
> 	Numbered sections and references. XHTML does not itself cause
> 	section numbers to be generated from headings. Style sheet
> 	languages such as CSS however allow authors to control the
> 	generation of section numbers.
>
> 	Surely they're talking about CSS 2 or 3, which I have no illusions
> 	about in the short-term. As a solution until that happy time, I
> 	suggest the <label> element could be both adequate and
> 	appropriate (it's "for" attribute would point to either its
> 	containing <h> or, if a separate element for reason of one's
> 	document layout, to a sibling or cousin <h> element).

I am advised as follows:
"The old <label> was used only with forms and is being removed along with
the whole forms mechanism which is being replaced by XForms.

There is a _new_ <label> element is specifically intended _ONLY_ for the new
<nl> element (the 'navigation list').  Of course you could use a span of a
specific class inside the <h> to represent a number too.

CSS2 is perfectly useable now for 'basic' automatic numbering.  The failing
with CSS2 is the lack of automatically-generated content for
cross-references. CSS3 is rumoured to have support for this but is certainly
a lot further off. CSS3 is also to be more tied to generic XML, rather than
CSS2 which worked mainly with HTML 4.0."

>
> >
> >(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>.
>
> 	I think that a combination of <l> and <span> elements is far more
> 	appropriate in such context -- as you say, that text block is not
> 	separate from the containing paragraph, so why make it so?

Thanks for pointing this out. We had missed that <p> would now allow the
lists to be contained. This is a very significant development.

Daniel's comments:
"Are you talking about using <l> as a list item and some sort of styling to
make it appear like a list. This would indeed permit you to contain the list
in the paragraph, and in fact wouldn't need
<span>:
    <p><l>Here is a list:</l>
         <l class="fake-list-item">Item 1,</l>
         <l class="fake-list-item">Item 2, and</l>
         <l class="fake-list-item">Item 3,</l>
       <l>and the trailing text.</l></p>

However if you want more than one level of nesting this way you can't have
it."

>
> >
> >(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.
>
> 	Your first statement seems an echo of (c), which I believe
> is handled
> 	by using the correct elements; the content model for a <p>
> allows lists.
> 	Because a <ul>/<ol> are distinct elements, and thus can be addressed
> 	and manipulated, I'm not understanding your second statement.

The point is to manipulate the while paragraph, introductory text and lists
as an object. This is now addressed, as you have pointed out, if the list is
included inside the <p> element.

> >
> >(e) The model retains the <ol> and <ul> which are redundant.
>
> 	I don't think they're redundant at all. In the absence of formatting
> 	directives, they simply provide a default presentation semantic.

We differ on this. That's part of the numbering problem.

"Default presentation semantic". Surely, the point of XHTML 2.0 appears to
be to use *less*
presentation and more real semantics.

>
> >
> >(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.
>
> 	It seems that you distinguish between document's outline and
> 	it's narrative content based upon the presence of a heading.
> 	Isn't this a just matter of adding or removing <h> (and <label>)
> 	elements from a <section> element?

No, the heading is not decisive to this, as explained in the proposal.

>
> >
> >(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.
>
> 	They're soon to consider deprecating those 6 elements, which
> 	makes much sense to me. Whether they do so or not, the <h>
> 	element (that you rightly used in the markup) could be the
> 	"standardized" element that we require be used in legal
> 	instruments.

Yes, they're supposed to be deprecating <h1>...<h6>.  Deprecating,
though, doesn't stop people using it.  Look at XHTML 1.0 and the number of
people
still using <b>, <i>, etc.
There would need to be a strict implementation.


>
> Thanks much for your answers. I promise not to ask more prior to
> Wed's call.
> John
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/lea
ve_workgroup.php.