[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-econtracts] Compromise Contract Structure,
John McClure wrote: > All, > I've thought more about Jim Keane's question -- whether another proposial can > combine the best of both worlds. Since "Section" is in both hierarchies, let's > try to leverage that, and address my basic issues: (1) Poor naming of lower > levels under "Section" (2) no "Clause" element and (3) No flexibility at upper > levels... Does this look alright to everyone? > > <Contract> > <Paragraph></Paragraph> > <Article> > <Paragraph/> > <Section> > <Paragraph/> > <Clause> > <Paragraph/> > <Clause> > <Paragraph/> > </Clause> > </Clause> > </SubSection> > </Article> > </Contract> > > Rules: > 1. Paragraphs contain NO captioning elements. > 2. Articles, Sections, and Clauses contain captioning elements. By "captioning element" i take it you mean heading. Does it contain PCDATA, or your "<en>" element? On the face of it <Paragraph> is not what we had in the teleconf, but rather, is like <p> as commonly understood? That would be ok, but i suspect your content model for Paragraph is still your <en> element, from your previous post: > <Section> > <Caption><en>SectionTitle</en></Caption> > <en>text for article, or is this text for a para in the article.</en> > <Paragraph> > <en>text for another para in the article.</en> > </Paragraph> > <Clause> > <Caption><en>Clause Title</en></Caption> > <en>text for section, or is this text for a para in the > section.</en> As I think you explained in a previous post, that "<en>" element is twisting the structure to fit the requirements of CSS. > 3. Articles and Sections are not recursive elements. > 4. Clause elements are recursive -- useful for levels 4+. So in essence you've replaced Paragraph, SubParagraph that the last teleconf was tentatively moving forward with, with a recursive Clause model. So now we are getting closer to: 1. Article, 2. Section, 3. Clause (cf the teleconf's Paragraph) 4. Clause 5. Clause etc I say getting closer to, since the list of selectors you give below shows you still aren't proposing a single tag per level. If it was a single tag per level, I could live with this. But even then it would be far from ideal, since by mixing recursive with non-recursive, you don't get the benefits of either, just the disadvantages: Disadvantages of non-recursive - moving clauses between levels eg moving a Section to the Article level - difficult to share/re-use clauses across documents (think clause library) since you need to always use it at the correct level Disadvantages of recursive - harder to write templates which format the level (you need something like [count(ancestor::Clause)=2]) - training issue for end users - raw XML is harder to understand without pretty printing - hard to use CSS to format We would be much better off with a model which is pure recursive, or pure non-recursive. Either is fine by me, but I'd caution against a mixture. > 5. All elements may occur multiple times > > This reduces the number of CSS selectors from 26 to 9: > Contract Article > Contract Article Section > Contract Article Section Clause > Contract Article Section Clause Clause > Contract Paragraph > Contract Article Paragraph > Contract Article Section Paragraph > Contract Article Section Clause Paragraph > Contract Article Section Clause Clause Paragraph > So there are still multiple containers per level! And if i'm understanding your model correctly, this is because you can always use <en> directly in a Clause, or Paragraph with an <en> child. You still have 9 selectors, and that is with quite shallow structure. Why not just: Contract Clauses Article Section Paragraph XXX1 XXX2 .. XXXn where the XXX have a name those with legal expertise care to nominate. I suspect we won't be able to resolve this until we've decided whether reasonable support for CSS is sufficient support for CSS, or we want to jump through extra hoops in the hope of getting CSS output which approaches the quality of output which XSL is normally used to achieve.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]