FW: Development steps for TC specification

[<civicsdotcom-oasis@yahoo.com>]

--- 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 ===