[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] August 17, 2004 Draft minutes
I came across this statement. I wonder if it is useful to the matters
under consideration..
Data Reuse. Entities can be quite useful in reuse of "blocks" of
information:
* Static Blocks. Mathematical formulas, theorems, and author name,
are examples of static "blocks" of information. Instead of including
them in a particular document, one can "componentize" them in separate
entity files. One can then have "many-to-one" (many documents accessing
one entity file) and "one-to-many" access.
* Dynamic Blocks. Legal or contact information are examples of
dynamic "blocks" of information. There are times when a company's legal
information (copyright, terms of use, acceptable use policy) have not
been decided at the time of production of a document. When encapsulated
in an entity, the legal information becomes independent of the document
production process, and can be added any time during the cycle. If the
company plans to move, the contact (postal) address will change. With
the use of entities, global modifications to the contact information
can be made readily. This is similar to the situation of a pointer to a
variable in C.
From: http://tech.irt.org/articles/js212/index.htm
Best regards to all.
John Messing
> -------- Original Message --------
> Subject: [legalxml-econtracts] August 17, 2004 Draft minutes
> From: "Dave Marvit" <dmarvit@pacbell.net>
> Date: Mon, September 06, 2004 9:43 pm
> To: "'Legalxml-Econtracts'" <legalxml-econtracts@lists.oasis-open.org>
> Cc: "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]
>
>
> 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/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]