[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-econtracts] XHTML 2.0 issues
Good to hear something back. My brief follow up is inline below. Thanks. Rolly Chambers ----- Original Message ----- From: "Peter Meyer" <pmeyer@elkera.com.au> To: "Legalxml-Econtracts TC" <legalxml-econtracts@lists.oasis-open.org>; "Chambers, Rolly" <rlchambers@smithcurrie.com> Sent: Tuesday, August 17, 2004 2:17 AM Subject: RE: [legalxml-econtracts] XHTML 2.0 issues > Hi Rolly, > > Thanks for the comments. I make some observations on three points you > raised: > > 2.2 - UBL > I'm no expert on UBL but I don't think this addresses the basic need to > define high level structure of a contract for purposes of structural markup. > At the most basic level, these containers are needed to simplify the > authoring process, control automatic numbering and allow the document to be > correctly rendered. They are not intended to detract from any semantic > information that may also need to be added. > > 3.2 - separation of content and display > Yes, the whole point of the structural markup is to separate content from > display. Going forward, I think we will need to establish whether this is > what we want to achieve as part of our requirements process because I don't > think it is fully accepted in the TC and is part of the reason why the > structural markup exercise may have been misunderstood. > > 4.1 - structure & semantic > Rolly says: > > [RLC - This may be assuming that there is a need to use XML only > > to publish large contract documents (a need served by > > "structural" markup), but no need to use XML to make the contents > > of contract documents more machine readable to facilitate the > > exchange of contract data with other systems for purposes besides > > publishing (needs served better by "semantic" markup). > > In connection with what I said in point 4.1, I think you have completely > misunderstood what I said. I apologise that my point seems to have been so > unclear. I have never assumed or advocated that XML is needed ONLY to > publish large contract documents. Nor have I ever asserted that there is NO > NEED to use XML to make contents more machine readable. My point was that we > need to find out the real requirements for a standard. I make no assumptions > about the end result. > > The structural markup initiative was designed to deal with the publishing > stuff first and to provide a common platform on to which semantic markup > could be added, by those who need it. > We started this way because I do not believe it is possible (at least > practicable) to do it the other way. > For what its worth, I believe that the semantic layer should be capable of > being added to any schema, not just the structural schema we develop. > > In retrospect, the proposal to move on the structural markup without > comprehensive requirements may have been a bad idea. It was proposed on the > assumption that the requirements process could be conducted in parallel with > it. Clearly that assumption was wrong. > > I remain very confused about the needs for semantic markup in a proposed > eContracts standard. > > Many of the possible semantic markup needs seem to me to apply to a wide > range of legal & business documents. If so, they may be beyond the scope of > this TC. That is certainly the case with the most of the semantic markup > needs that emerge from the negotiated contracts scenario I posted. I accept > that it may not be true with other use cases. > > Another problem I have is a perception that some people want a standard to > encompass every aspect of a very specific transaction model they have in > mind. Its almost as if they want to embed their business model in the > standard. I believe a standard must avoid this. The standard should allow > people to work the way they want to work and allow technologies and > processes to evolve. It should define only those processes that are > necessary to support a widespread business need. If we try to reflect very > specific transaction models, how many models must be supported and at what > complexity in the standard? That approach seems to be inconsistent with what > standards, particularly new standards should try to achieve. > > These problems are not insurmountable. We just have to start at the > beginning and work out what we are trying to achieve. In that process we > should be able to work out the common needs of a wide range of user groups > and develop a standard to meet those needs first. Having had a quick read of > your use case, I am fairly sure this process will allow us to achieve this > goal. It will take some work and we will each need to be open to review of > what we think are our requirements. > > Regards > Peter > > > > > > > > > > -----Original Message----- > > From: Chambers, Rolly [mailto:rlchambers@smithcurrie.com] > > Sent: Tuesday, 17 August 2004 1:56 PM > > To: pmeyer@elkera.com.au; Legalxml-Econtracts TC > > Subject: RE: [legalxml-econtracts] XHTML 2.0 issues > > > > > > My comments are below. > > > > This is a helpful explanation of the thinking behind the recent > > structural markup proposal. > > > > Rolly Chambers > > > > -----Original Message----- > > From: Peter Meyer [mailto:pmeyer@elkera.com.au] > > Sent: Mon 8/16/2004 10:13 AM > > To: Legalxml-Econtracts TC > > Cc: > > Subject: [legalxml-econtracts] XHTML 2.0 issues > > Hi folks, > > > > Some points on XHTML 2.0, as discussed at the last meeting. > > > > 1. Background, why we chose XHTML 2 > > 1.1 Some of us could not agree on a completely new structural > > markup model. > > > > 1.2 XHTML 2 introduces a structural model into HTML using > > recursive section > > containers and p containers. > > > > 1.3 This motivated some of us to think that it would provide a > > close enough > > starting point for contract markup. > > > > 1.4 XHTML 2 seemed attractive because it is XHTML and would be an easier > > sell to developers than an entirely new schema. > > > > 1.5 It was perceived as an advantage of XHTML 2 that it would > > make it easier > > to transform eContracts for web publishing. > > > > [RLC - could be but I think ease (or difficulty depending on your > > perspective) of transforming eContracts for web and other > > publishing will be comparable whether XHTML2 or some other XML > > dialect is used.] > > > > 1.6 Some of us believed (and still believe) that straight XHTML 2 > > markup was > > too loose to be useful and that we must strip it down to a simple model to > > make it easy for authors, easier for application developers and useful for > > content management and document production. > > > > [RLC - Agree heartily with simplifying straight XHTML 2 and > > approve of the effort to date. I'd encourage the subcommittee to > > try simplifying further if there is any consensus to do so.] > > > > 1.7 For my part, I promoted XHTML 2 on the basis that it should give us a > > markup model based on one that would become fairly familiar in the > > marketplace over the next few years, that we could shape to our needs and > > that this would give us a marketing advantage we would not enjoy with an > > entirely new schema. In summary, the advantages of XHTML 2.0 for me were > > more marketing than technical. > > > > [RLC - agree.] > > > > 2. What we have learned > > 2.1 A strict version of the section and p markup is capable of meeting our > > clause model needs, although its not perfect. For example: > > (a) HTML lists are not suited to real documents that require flexible > > numbering schemes > > (b) Some aspects are not well thought out, such a the l element. > > At this level we could use something that is a subset of XHTML 2.0. An > > eContracts schema could not accept most XHTML 2 markup but it > > would be easy > > to go the other way. > > > > [RLC - the "other way" being that an XHTML 2 schema/dtd would > > accept eContracts markup?] > > > > 2.2 XHTML 2 does not have an obvious way of providing the high level > > structure found in contracts. We are faced with either using (over using) > > the div element or inventing new elements. There is disagreement about how > > many are needed and the design approach required. > > > > [RLC - UBL appears to use a different design approach. UBL 1.0 > > provides "a library of XML schemas for reusable data components" > > and "a small set of XML schemas for common business documents > > such as 'Order,' 'Despatch Advice,' and 'Invoice' that are > > constructed from the UBL library components . . . ." "The UBL > > library is designed to support the construction of a wide variety > > of document types beyond those provided in the 1.0 package . . . ." > > > > In effect, the components in the UBL "library" (which have > > semantic names but are components in the same way as our proposed > > section and p elements) are not pulled together into the single, > > high level "one structure fits all document types" manner that we > > are exploring. Instead, the UBL components are combined in > > different ways to assemble eight different document types. > > > > I am not advocating a UBL-type design approach -- just observing > > that it is an alternative. If followed, this approach would allow > > sections and paragraphs to be assembled in varying ways. Section > > and p could be assembled in one way to offer structure for > > lengthy formal contract documents of the type Jason has cited > > examples of. These same components also could be assembled in a > > different way for more informal types of contract (and other) documents.] > > > > 2.3 Some new inventions are essential, including signature blocks > > but there > > are differences about how to design markup for these. > > > > [RLC - agree that eContracts will need a place for information > > customarily found in paper "signature blocks." This is not the > > same as digital signature info in my mind.] > > > > 2.4 There seem to be some strong differences within the TC about > > the meaning > > of generic structural markup, the need to support human authoring of > > contracts using XML editors and the role of XML in "the contract". > > > > [RLC - agree there are differences about what constitutes > > "structural" markup. In a sense, even "structural" markup > > elements are semantic -- it's just that their semantics are > > generic and don't describe the information they contain in a > > particularly meaningful way.] > > > > 2.5 There seems to be some support for implementation of our own > > namespace. > > > > [RLC - agree we should define an eContracts namespace.] > > > > 3. What do we need from XHTML 2? > > 3.1 Do we need strict conformance to XHTML 2? I suggest this is not > > particularly important. Its an unnecessary straight jacket and we > > should use > > it only while its convenient. Most of the benefits will flow if > > we can keep > > to the section and p markup that has some prospect of becoming > > familiar to a > > fairly wide community, particularly if other legal and business document > > markup standards use a similar schema. > > > > 3.2 Do we need XHTML 2 to publish eContracts on the web? Increasingly, any > > XML markup can be rendered on the web using style sheets. The use of XHTML > > markup may make this a bit easier but in the vast majority of contract > > documents this may not be very important. > > > > [RLC - the ease or hassle of using stylesheets or scripts to > > publish XML documents looks unavoidable to me. It's the result of > > assuming that "separation of content from display" is a good thing.] > > > > 3.3 It is not clear what else we really need from XHTML 2.0 or how closely > > we should stay within its constraints. > > > > > > 4. Conclusions > > 4.1 The critical issue is that the schema we adopt or develop should meet > > the needs of the proposed standard. At this stage, these needs are > > insufficiently defined for us to be able to resolve the issues, such as > > those mentioned in 2.4 above, that have been with us since > > formation of the > > TC and for years before in the old Legal XML. > > > > [RLC - This may be assuming that there is a need to use XML only > > to publish large contract documents (a need served by > > "structural" markup), but no need to use XML to make the contents > > of contract documents more machine readable to facilitate the > > exchange of contract data with other systems for purposes besides > > publishing (needs served better by "semantic" markup). > > > > From my perspective, TC members are interested in more clearly > > defining both needs and have agreed to have a go at the > > "structural" markup first. However, that does not imply a lack of > > interest in or need for "semantic" markup.] > > > > 4.2 Until we complete the requirements process we will not be able to > > resolve the outstanding issues about the use of XHTML 2. > > > > > > regards > > Peter Meyer > > > > > > > > > > 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/m > embers/leave_workgroup.php. > > > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]