[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-econtracts] Overall requirements - structure v semantics
thanks John for your reply. i guess the key question is what must an "exchanged file" contain? clearly it needs to contain the words of the contract. and if this "exchanged file" is to be the/a subject of our standardisation efforts (probably this is one of the key questions we need to be discussing as part of the requirements process...), then it probably makes sense to restrict the bit containing the words of the contract - ie the structural bit - to be an XML file. but do we need to restrict ourselves to one "common schema" for that structural XML file? why can't an author use whatever they like for it, as suggested in the box below: +------------------------------------------------------------------+ | | | Structural layer | | (eg eContracts structure, WordML, XHTML 1, XHTML 2, SVG etc)| | | +------------------------------------------------------------------+ what do we gain by mandating a particular structural grammar? (thanks for reminding me that SVG is a candidate here as well...) if we do have separate "authoring" and "publishing" DTDs, then i don't see why you couldn't use either of them for the structural layer? returning to the "exchanged file", i would say that the semantic layer should be optional. we need to say how it would be expressed (ie using RDF or some other mechanism, or maybe a choice of several), but i don't think it should be compulsory to include semantic stuff. but again, this is a question we need to discuss as a TC -- maybe there is some minimum amount of semantic information we regard as critical eg the party names? thanks Jason John McClure wrote: > Good note, Jason. A few comments. > > 1. The XHTML @property attribute is the place for inline semantic markup, that > is, XHTML provides adequate support for those dialects already - so I don't > think we need to specifically address any particular vertical. Non-normative > examples (in the tech spec) that use them are fine, but normative material > should not. I definitely do not want WordML mentioned in any normative section. > > 2. The notion that we are more defining an architecture -- with a specific > implementing markup schema -- is one that I've had for awhile also, however > there is a crucial presumption at work here worth reviewing. To me, the > contract -- produced by an XSL-T -- ultimately must conform to a common schema. > That common schema is best made XHTML 2.0 based, ie the Publisher schema, in > order to meet presentation fidelity requirements. This view does track with what > I've earlier said -- the PPT I once posted to the list (and attached here), > shows that the common end-point of a contract doc is a digitally-signed package > that contains > (1) an XHTML or SVG file (called the "User Agent" XML file), with or without > inline > @property markup for semantics that are 'agreed-upon by the parties' > (2) RDF file(s) reflecting semantics (not) agreed upon by the parties; and > (3) other files needed for authoring, presentation, or management > > 3. Maybe you're now arriving at the same conclusions as me about what > constitutes the "exchanged file". The definition of what an "exchange contract" > _is_ has bedeviled our conversations to date, leading I think to several > unfortunate miscommunications. As you know, I think the authored-file (that > precursor to the normative XHTML file) would rarely if ever be an object of > exchange between parties. Further you probably understnad that since my focus is > solely on "that-which-is-exchanged", then my impatience with precursor formats > is sometimes palpably clear. I'm sorry for that, because I do understand (and > support) the central importance that authoring plays in yours and others > requirements. In this vein, I am optimistic that having a separate schema for > Author v Publisher is a potentially fruitful path for us all. > > Since the definition of an "exchanged file" certainly is an item that needs to > be discussed in the requirements document, your comments below are quite useful. > Thanks, > John > > >>-----Original Message----- >>From: Jason Harrop [mailto:jharrop@speedlegal.com] >>Sent: Sunday, July 25, 2004 6:19 PM >>To: legalxml-econtracts@lists.oasis-open.org >>Cc: Mary McRae >>Subject: [legalxml-econtracts] Overall requirements - structure v >>semantics >> >> >>The agenda for our August 3 meeting includes: >> >> >>>2. Review our requirements document with the goal of reaching closure >>> and/or determining what changes must be made so that we could vote on it. >>> >> >>My view is that the requirement document should have teeth, that is, to >>be something which reflects decisions made by the TC which have a useful >>impact on the standards being developed. >> >>If it is to have teeth, then i think there is still a lot of work to be >>done on it. >> >>In addition to preparing descriptions of specific business contexts as >>suggested by Peter, a useful approach might be to try to create a list >>of half a dozen or less key issues/themes, which we can discuss one by one. >> >>For me, one such issue would be the relationship between the structural >>and semantic layers. >> >>Working Draft 3 (10 April 2004) of Rolly's document contains at 4.1.5 >>the requirement that our XML syntax for contract documents "should be >>compatible with various XML semantic vocabularies or dialects, including >>those used in different vertical business sectors". >> >>It seems to me that there are various questions that we need to discuss >>and resolve one way or another. There are two key ones: >> >>1. Do we want to support various existing vertical XML standards (such >>as ACORD for insurance, ISDA's FpML for financial products such as >>swaps/derivatives, real property), in addition to a semantic vocabulary >>we as a TC devise? >> >>2. Are we saying people have to use our eContracts structural for >>contracts, or are we explaining a conceptual model which has a >>structural layer, and saying you can use whatever XML document format >>you like for that purpose (eg eContracts structural, WordML, XHTML 1, >>XHTML 2, DocBook etc)? >> >>I'd love to hear where TC members sit on these issues. Fwiw, my 2 cents >>are further below. >> >>Once we know the answers to these two questions, we can look at possible >>technical solutions (eg inline markup, RDF, XForms, devise our own >>mechanism, or some combination). >> >>--------- >> >>Jason's answers: >> >>To question 1: I think that if we can do this in a clean way, without >>imposing unwarranted technical hurdles on people who might be >>considering using our work, then our contribution will be that much more >>compelling. I'm keeping an open mind, and could go either way on this >>still. >> >>To question 2: If the answer to question 1 is that we should be >>supporting existing vertical XML standards, then i think we have to be >>saying that people can use whatever structural layer suits their needs. >> >>I say this because even if our structural layer becomes very successful, >>there will still be a lot of people who author contracts in Word 2003. >> >>Word 2003 already includes a structural layer - its called >>WordProcessingML, and it includes paragraphs, tables, and some other >>stuff (including a lot of presentation). When you use WordProcessingML, >>it seems to me there is little reason to also use our section, h, p etc. >> >>But, there is a lot to be said for using WordML in conjunction with a >>semantic schema. And this is precisely what Word is designed to make >>very easy. It does this by validating the structure against WordML >>schema, and simultaneously but independently validating the semantics >>against your contract semantics schema. (You could see their US patent >>application number 20040006744 for a description: >> >>http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG > > 01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040006744%22.PGNR > .&OS=DN/20040006744&RS=DN/20040006744 > > For downstream business users, its this semantic data which is critical, > and which Word 2003 is designed to make easy to extract. > > So if we are intending to support different vertical schemas, our > complete model would look something like: > > +-----------------------------------------------------+ > | | > | Semantic layer (vertical XML schema) | > | (eg ACORD, FpML, or eContracts semantics) | > | | > +-----------------------------------------------------+ > || > +-----------------------------------------------------+ > | | > | Connection mechanism (to be specified) | > | | > +-----------------------------------------------------+ > || > +-----------------------------------------------------+ > | | > | Structural layer | > | (eg eContracts structure, WordML, XHTML 1 or 2)| > | | > +-----------------------------------------------------+ > > > cheers, > > Jason > > > 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_w > orkgroup.php. > > > !DSPAM:4107de5532192268836741!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]