August 17, 2004 Draft minutes

[Dave Marvit <dmarvit@pacbell.net>]

Folks,

Here are the draft minutes of the August 17th  conference call.

-Dave

---------------------------------------------------

LegalXML eContracts Draft minutes
August 11th conference call


In attendance:
Dr. Leff
Zoran Milosevic
Dr. Colyen Sue from the W3C (As a guest of Zoran's)
Jason Harrop
John McClure
Peter Meyer
Dave Marvit


[Discussion about the logistics and cost of the Coala conference]

John: What is the goal of the face-2-face? I'd like to achieve thing 
rather than just socialize.

Peter; I agree. I think we have been having trouble because we don't 
know what we have been trying to achieve on a broad scale. We will have 
to distil out of the use cases what we are trying to achieve. I don't 
think we have a common understanding.

John: So the notion is to review the use cases and find the specific 
function requirements that we can all agree on, then to take those 
statements of consensus and anchor our requirements to those?

Peter: Yes, I think that would be an achievable thing, and it would 
take us forward. What do you think?

John: Yes. It would be useful, perhaps, to identify an agenda, an order 
of discussion, and to allot a specific amount of time to each subject 
and to not spill over.

Peter: Yes, I agree. A detailed agenda would help. We need to ask our 
chairman to take a firm hand.

[Discussion of venue of the F2F]

[Discussion of what level the discussion of XHTML2 should take place]

John: There have been 2 flavors of notes on the list. The first was a 
set of bullets that described the differences between XHTML1 and 
XHTML2. There was another set of notes discussing whether we should be 
using XHTML2. So there are 2 ways of slicing it today.

Zoran: I would like to learn a bit more about XHTML2 - along the lines 
of what you posted. Then I'd like to know what benefits we are likely 
to find.  Should we adopt the ideas? The thinking? Would it be a 
straight mapping form our ideas to XHTML2’s? And then, is it a 
marketing issue? If we are starting to prune XHTML2 do we still attract 
the software developers that we want? So these are the questions I'd 
like to ask. I think it is good to put this on the table again.

John: So it sounds like you'd like the order of biz to be: discuss the 
changes and then the other issues.

[Agreement]

John: So, I'll review the 4 areas of change.

1 Semantic markup is supported by XHTML2. Embedded within the text of 
the document. They have introduced attributes: property, resource, and 
about. These were drawn from RDF.

Property can be used to encapsulate an element

Resource and about can be used to point to URIs.

They do have some discussion of how to link an ontology (not 
necessarily RDF) that would be linked to the XHTML2 document.

Beyond semantic markup they have fixed a number of issues by adding and 
dropping elements. They added the section element, the H element, the L 
element, and the NL element.
Section is to be used like a DIV. it is recursive. It seems to be 
intended to be used for numbered sections (that's my interpretation). 
It is used to distinguish content in a section of some kind from 
content in a DIV.


The H element was introduced as a way to walk away from the H1 to H6 
element.

Z: Sorry… can you make clear the different between section and DIV?

John: The notion of having definable sections within a document... The 
definition of a div is much like what we call an add in element. The 
definition of DIV relates to content that is not otherwise accommodated 
by the HTML dialect. The section element is, as best as I can tell, to 
be used for the purposes for numbered items, to be integrated with 
style sheets that reference numbering algorithms of one kind or another.
One could use a DIV for numbered sections but it was thought, near as I 
could tell, that would lead to some very complex CSS statements. As far 
as I could tell it was felt that for HTML streams that they needed to 
identify content that needed to be numbered in some way.

Zoran: So we use section when there is a need to do numbering, and DIV 
when there is no need...?

John: That is my reading. The spec doesn't exactly say that, but it is 
my reading.

Colyn: The sections was created to be used with H, because without 
section you won't know what is nested and what is not.

John: but you could use div for that?

Colyn: Yes, but DIVs are used in so many crazy ways...

Dr. Leff: So why DIV?

Colyn: Very similar to metatag in the early days. It is a placeholder 
for...

Dr. Leff: I see. So the text that might be italicized would be placed 
inside DIV tags and the CSS would then italicize it.

Colyn: Yes.

[discussion of Dr. Leffs ideas of inheritance]

Zoran: Are you proposing that we use section, DIV, and all other XHTML2 
elements as part of the XHTML2 namespace, or are you proposing that 
these elements will be prefixed by our namespace? Are you proposing 
that we create our own section, but it does the same thing as XHTML2's 
section?

John: The answer to that question is 'maybe'. I hate to put it that way 
but it comes down to whether we want to have a conforming dialect. If 
we do then there are real issues with constraining the content models. 
If we do not wish to conform then it is even open as top weather we 
have to establish a namespace. It gets down to the extent to which we 
want to conform to XHTML2 and if we want to create a legal module. If 
not, then we are not constrained by some of the items that are 
mentioned, like the issue of whether we allow PC data.

Zoran: By conformance we mean conformance in what sense?

John: Technical conformance. There are certain requirements that 
conforming models have to adhere to.

Zoran: But if we run it down we don't conform?

John: Right.

Zoran: And both you and Jason are agreeing that we need to get rid of 
PC data.

John: If we were to establish our own data model then the data stream 
would have a legal: section rather than section.

Zoran: Well, I don't see such a large rift.

John: Well, what is a crack to one is a rift to another.

Jason: There is a fundamental difference to me. They might have a 
content model that looks very similar if you take away the namespace, 
but they are fundamentally different if they have different namespaces. 
If we prune the section element then it is no longer an XHTML2 section 
element, it is a legal: section element, and that is perfectly 
appropriate

Zoran: Right, but I am seeing that John agrees with you

Jason: Right, but we should be under no illusions that we are making a 
significant choice

Zoran: But you are in agreement?

John: Yes. The only pint of disagreement on this particular issue is 
whether the group would put out a style sheet that would convert 
between the 2 section elements, but that question is down the road.

John: So, in addition to the section element and H element they have 
introduced the line element and the NL (Navigation list) element. They 
have dropped a number of elements. Jason may know better than I what 
elements have been dropped. Jason?

Jason: Well, in my opinion no significant elements have been dropped.

John: All of the form related elements have been dropped, along with 
italics and bold... They have also tightened up the content model for a 
number of elements... Jason...

Jason: I don't know that for present purposed there is anything to 
bring up here. Is there?

John: I don't think P can contain DIV anymore. That's the main item 
that I was thinking of. They also dropped some attributes that dealt 
with styling. Anything else?

Peter: I think you've covered the important points. The important issue 
is whether we want to diverge form the XHTML2.

DM: What price do we pay if we *don't* diverge

John: Users who are entering a contract into a schema driven editor 
would be confronted with a number of options that might be confusing. 
For developers there would be unnecessary complications..

[Dave had to drop off temporarily]

John: Even though we are calling it a section element, by prefixing it 
with a legal namespace we are making a representation that it is an 
XHTML2 element. Is that what you are saying Jason?

Jason: No. Section in our namespace belongs to us. I think it is 
entirely appropriate for us to use the same name.

Dr. Leff: If our section is a subset of the XHTML2 section, it should 
do something reasonable. If we don't add so that it would break things 
then that should do the right thing.

Jason: With due respect, if it is in a different namespace then that is 
a whole new ballgame.

[Discussion of how generic programs will deal with legal: section]

Dr. Leff suggests that a generic program would not have a problem with 
a legal namespace when interpreting the legal: section as long as ours 
is a subset.

John: Dr. Leff, you are right, and that is the impetus behind the 
modular ... However, in our content model it is a constrained version 
of the other... because it would not find any unexpected content..

Jason: We are not quite constrained. We have the Nr element and the 
inline list element.

Dr. Leff: Well, if we made additions then everything will break.  Can 
we not make additions?

Peter: That is too constraining. Why are we so concerned to maintain 
this 1 to 1 mapping?

Dr. Leff: In the context of this hypothetical software.

Peter: Surely we would be building our apps on the applications that 
can work with arbitrary schemas.


Jason: The two main pieces of software, browsers and editors, can 
handle any XML. As you are aware programmers can handle any XML. The 
bits of XHTML2 that are valuable, I believe, are the X-forms model, and 
potentially the RDF stuff. Those parts of XHTML2 we can import into our 
own schema if we want to .

Jason: XHTML2 is a good representation of a web page, but not of a 
contract.

John: Why?

Jason: Put both in front of a lawyer and they won't look the same. A 
lawyer is going to be much more familiar with background and clauses 
and so on than they will be XHTML2 commands.

John: Why is this different from giving them a word document and the 
code that represents the word doc? You are suggesting that the primary 
reason XHTML2 is not reasonable is that an attorney will reject having 
to mark up their contract using XHTML2. It seems that you are talking 
about the data representation and attorneys never use that...

Jason: We could write a long explanation explaining how we could…

[discussion about he fact that the schema itself should impose the 
constraints. Otherwise we would effectively be imposing application 
level ‘pseudo-schemas’. And that would defeat the purpose of XML]

John: I differ. The purpose of using XML is to allow us to exchange 
contracts in XML.

Peter: It won't work in the real world. Programmers won't follow the 
rules. There is no way that we will all do the same things in our 
applications.

John: I think it would be a good standard if you could mark it up in 
your way and I mark it up in my way.

Peter: Why is that good?

John: Because it provides flexibility to the author.

Dr. Leff: Why do we want to provide flexibility It is like providing 
flexibility for a purchase order. We want it to…

John: In a PO you use elements to ...

Zoran: The very fact that we would need to add semantic issues later... 
we need to be careful about the constraints with XHTML2. I thought we 
had a good understanding that we are building our own schema. A lot of 
these concepts from XHTML2 have helped us build... From a marketing 
perspective we can say that our work has been inspired by XHTML2, but 
we need to agree how to move on. I am not sure that anyone thinks that 
having strict compliance is necessary...

Dr. Leff: We have gone almost in a full circle.

Peter: When we started on XHTML2 we were going to prune it.  We were 
never going to use it in the raw. What we didn't understand was the 
conformance issue and what it may mean.  Stripping things down makes it 
harder to be compliant. Adding things is easier.

Jason: I don't think we have gone in a circle. That implies that we 
have come back to where we started and we haven't achieved anything. 
That's not true. We are on a path. We hadn’t talked about namespaces at 
all. We... it was really after the current phase of the SC work.. it 
was Zoran who suggested by asking if the section element is in our 
namespace or the XHTML2 namespace. That question crystallized the issue.

I'd like to make a second point. If people are free to use the XML 
structure or some other structure, say docbook, people will use 
whatever one is most useful to them. If you have that view of the world 
then there is one benefit to making our structure similar because you 
have removed the choice. Anyone who wants to use that can.

Zoran: I didn't mean that you guys haven't accomplished a lot. I think 
you have.

Dave: I asked the question about the costs of not conforming, and I 
think that sent the discussion down a certain path.

John: Yes, and my answer is that there are costs to the user and to the 
developer. I want to ask Zoran for your own sense if we will be adding 
elements to the section element that are specific to legal?

Colyn: You already have, in the numbering.

John: I want to know if your goal is to have new legal semantic 
elements. Do you foresee that by establishing a legal section element 
we are laying the groundwork for standardizing many legal elements?

Zoran: Many legal elements...?

John: For marking up dates and times...

Dr. Leff: That brings us up to the horizontal issue, for creating a 
legal name space for all of LegalXML.

Zoran: Well, my answer to John is that we can establish various 
mechanism to link up elements. However, I wouldn't want to drive the 
discussion into this direction. However the fact that we are creating 
our own namespace and our own schema gives us freedom not to worry 
about XHTML2 and its constraints. All the way from simple data type, 
date and price and so on... all of the things that are relevant to 
every contract.. Then later on we can think about other more complex 
things that Dr. Leff has talked about.

So, for that matter, I wouldn’t... I'd like to focus on the 
requirements...

Peter: I think that was an important point about the requirements. It 
is almost always a mistake to coerce your requirements to meet the 
tools. We set out to take XHTML2 and adapt it, but we have fallen into 
a situation where constraints are being imposed by XHTML2.

Zoran: In the next few years there will be more powerful tools that 
will allow us to move between different models.

Peter: I'd like to establish a principle on this point -- perhaps a 
straw pool... on whether we can establish our own namespace

John: I'd like to have a distinction between a modular namespace or a 
non-modular namespace.

Jason: I'd like to know if it is a legal: section or just a section.

John: So we can still have a legal: section and still be a modular 
namespace.

Jason: OK. I'd like to ask if we are using legal: section and legal: p

Zoran: Is this necessary? I thought we all agreed.

Jason: That'd be great, but I don't think that we all agree

John: Well... I joined the SC because I wanted to have a hand in 
shaping what is proposed and what is presented to the TC. I went in 
saying that we should use a style sheet that certifies the data stream.

Peter: Style sheet...?

John: A separate schema that is used for authoring only. Bottom line, 
If I were master of the universe, which I am not, I would be voting for 
a strictly conforming legal namespace that conforms as much as possible 
to XHTML2.

Jason: Maybe another way to put it would be to think of section 
downward -- section, H, P, NR, and the stuff inside the paragraph; Are 
they all to be in the LegalXML namespace, or could some of them be in 
LegalXML and some in XML.

Zoran: But I thought that we had agreed that they would all be in our 
namespace?

Jason: Yes, but some might not agree

Pete: In developing our schema, I propose that we are not constrained 
by or limited to the XHTML2 namespace or the XHTML2 modularization 
rules.

Zoran: I would ask that the cost of complying or not has already cost 
us a lot. I think that we have decided that we want to have our own 
schema and would try to move on. It did help us bring in all of thee 
key concepts which will allow easier transformation later on.

Colyn: It seems like a fair question to ask at this point. If you make 
the decision not to be limited by XHTML2 then the cost of being limited 
by it will be eliminated and you will be able to move a lot faster.

Peter: The motion is: “In developing our standard we are not 
constrained by or limited to the modularization rules of XHTML2 or the 
XHTML2 namespace.”

[John seconds as a nonbinding straw vote.]

John: I will vote first. I absolutely disagree. I believe that we 
should be constrained.. that we should build an XHTML2 compatible 
specification because that will be the best path towards success.

Zoran: We are building a compatible standard. It is just that we cannot 
claim that we are conformant.

John: No, you are not being compatible. If you want to get to the 
semantics you don't go creating party name elements, you use the 
property attributes. The clear intention of this group is going to be 
to add elements that should be attribute value.

Peter: That's a constraint you are bring in from XHTML2

John: Yes.

Jason: I would agree with Peter, noting that it leaves us free to use 
the property attributes later if we want to.

Zoran: And whatever else we want to do.. as we find it needed.

Peter: In favor of the motion.

Dr. Leff: I'll vote in favor and note my regrets that there is not 
software based on XML. There isn’t software that will take the software 
and those inherited elements and do anything useful with it.

Zoran: I also vote in favor with the objective being to try to build 
our own semantics - covering structural and other.

Dave: Also in favor. I don’t believe that we should suffer the 
constraints if we don’t need to. And it seems perfectly in keeping with 
the spirit of XHTML2 to add and use a namespace.

Dave: The motion passes.

[Dr Leff will post the use case soon the web.]

Next meeting: the 7th..?

Jason: The 7th is fine, but can we work out a an agenda on the list. If 
we have a problem then we can discuss it on the 7th. And we will 
discuss the use cases on the 7th.

Zoran: Is there any form of follow-up that the structural SC needs?

Jason: It would be useful to, at the F2F, see some structural markup 
working. If anyone has some editing tools that they could bring along. 
Obviously I'd be interested in seeing the structural markup that we 
have proposed. If you, John, are going to continue with your minority 
report then I'd like to see it working as well.

Peter: That is a great suggestion. I think it would be very helpful.

[Meeting adjourned]