[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Development steps for TC specification
--- Peter Meyer <pmeyer@elkera.com> wrote: > Dear TC members, > > Please can someone post this to the list for me. I > am unable to do so. > > > By now, you should have the BNML eContracts schema > package I posted earlier > that constitutes Elkera's contribution to the TC. > Please let me know if you > have not received it or if you have any questions > about it. > > That package includes several example XML files > using the schema. One of > those examples is the eBay user agreement and > privacy policy we looked at > last week. I have added annotations to the marked up > document in several > places. > > At our last meeting, I was asked to provide a list > of steps we need to take > to continue our development. I set out some of the > major points below. I > think we should settle this list and establish a > timetable to try to work > through them. I apologise for the delay in > finalising the schema licensing > but this is now behind us. > > List of development steps or stages: > > > 1. Schema architecture > We need to decide the high level issues about the > TC's proposed schema. Some > key issues are set out in the following points. > > 1.1 Is it a development platform or smorgasbord? > 1.1.1 Background > The issue is whether to create a basic, development > platform or a > smorgasbord schema that tries to cover all > possibilities. > The BNML Schema provides a basic model that can be > easily adapted by > particular users to their needs while retaining the > core content models. The > idea is to not overload the schema with things that > a lot of users may not > need but to provide all the basics so that > applications developed around the > schema can be easily adapted to deal with changes. > This is also the approach > taken by DITA, although it uses a different > specialization model to that in > BNML. > Schema such as DocBook take the smorgasbord > approach, but do allow > customization. > > 1.1.2 PM recommendation > It is impracticable, particularly at this time to > develop a universal schema > that will fully satisfy all needs. There is no > identified need for such a > schema. There is no need for widespread exchange of > eContracts documents > between enterprises since there is no infrastructure > for recipients to deal > with it. As the need arises, particular interest > groups who want to exchange > data can define standards for the purpose. > I recommend that we keep it as simple as possible > and define a base model > that can be easily extended by particular users, > along the lines of the BNML > approach. I don't think it is necessary for us to > use the DITA approach to > specialization for contracts. > > > 1.2 Do we include document types other than > "contract"? > 1.2.1 Background > You will notice in the eBay user agreement, I have > added the privacy policy > as a "document" that is attached in the adjunct > element. This adds > considerable flexibility to the schema but may or > may not be necessary for > particular users, depending on the approach they > take. > In theory, if particular users want to add > "document" or other document > types, they can easily do so by borrowing from BNML > or developing their own. > > 1.2.2 PM recommendation > Adding the "document" document type or something > similar makes the schema > very flexible and makes it easier for others to see > how the schema can be > extended in other legal areas. The TC has an > interest in the adoption of its > model by other legal and business users. Unless this > occurs, the schema's > market penetration will be extremely limited. > On balance, I recommend that we include the > "document" document type to > provide this flexibility. > > > 1.3 Which schema syntaxes do we use and which is > normative? > 1.3.1 Background > We have a choice between Relax NG, XSD (XML Schema) > or DTDs. We canvassed > the issues in 2003-2004. Due to the different > capabilities of each, we may > need to select one syntax as the normative schema. > This decision will likely > depend on the architecture of the schema. If we want > to provide features > that are not supported by, say, DTDs, then we will > need to use either Relax > NG or XSD schema and make it the normative version. > This does not prevent us from making the schema > available in all 3 syntaxes > for the convenience of users. This is the approach > taken in BNML, although a > full DTD has not been created at this time. > The BNML schema uses Relax NG for several reasons: > * BNML re-defines the item element in the //block > context. This cannot be > done in DTDs; > * Relax NG is extremely flexible and excellent for > customization; > * There are tools to automatically generate XSD > schema from Relax NG > * The Relax NG compact syntax is reasonably close to > DTDs and is very human > readable. XSD schema are XML documents and very > difficult to read. > > 1.3.2 PM recommendation > I believe we must provide a schema because some > applications do not support > DTDs (MS Word). > The choice may depend on whether the TC retains the > re-defined item in > //block in its schema. If it does, I recommend we > use Relax NG as the > normative schema syntax. Even without this, I > believe it is the most > appropriate syntax. > > > 1.4 Schema name and XML name space > 1.4.1 Background > The TC does not have to use "BNML" and may not wish > to do so. The TC can > decide on its own name space and schema name. > > 1.4.2 PM recommendation > Develop a new name for the eContracts schema. > > > 2. Detailed schema design and development > Once we have established the overall architecture, > we need to complete the > detailed schema design. Some issues we will need to > consider include: > > (a) whether we want to change any of the element > names for BNML elements > adopted in the schema. > > (b) Whether we need a more flexible or structured > model for handling > contract front matter and parties. > > (c) Whether the party-signature model is > sufficiently flexible. > > (d) whether we need to markup in-line lists > > (e) whether we need to add a list container and > separate list item to > provide for separate numbering control on multiple > lists in a single > paragraph or block. > > (f) whether we need to allow adjunct to occur at the > front of the document > for reference schedules. > > (g) whether we want to define specific attribute > values for //inclusion > attributes, automatic numbering control and on other > elements. > === message truncated ===
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]