[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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=PG01&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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]