OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-csc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ubl-csc] (2) Review packaging


[Eve:]

| Sorry to ask dumb questions (I'm sort of out of the loop at this
| point), but...  I'm confused about the notion of making the Naming
| and Design Rules just be a "chapter 3" of some larger document; as
| it is, it already nests pretty deeply.

[Mark:]

| I strongly disagree with infusing the NDR document into a larger
| package.  They must remain separate, as they are in fact separate
| focuses.  To meld them together will result in resistance to
| library based on NDR, and to NDR based on library. True the
| library content is (should be) based on the NDR document, however
| the NDR document is in fact a stand-alone document that can
| operate completely independently from library content.

I think there's some confusion here around the words "package" and
"document."

When UBL is published as an International Standard, it will likely
consist of three parts:

   Universal Business Language -- Part 1: Naming and Design Rules
   Universal Business Language -- Part 2: Library Content
   Universal Business Language -- Part 3: Context Methodology

Each of these parts will constitute a separate, standalone
document.  No one is suggesting that we subsume any of these
pieces within any of the others.

Our task this week is to make two of these *documents* (Part 1 and
Part 2), together with a fairly large number of supporting pieces,
available to reviewers as a single *package* that can be
downloaded in a single *file* that the reviewer can install with a
single "unzip" and access as a single set of specifications so
that we can manage this review cycle in an orderly way.

The only way that I (or anyone else in this conversation so far)
has been able to figure out how to accomplish this easily is to
roll both documents and all their supporting materials into a
single zip archive along with an html index that pretends to be a
document called the Review Package.  There are several advantages
to this approach.

 - The html index can easily be installed on our web site as a
   single web page containing pointers to all the subsidiary
   pieces.

 - The same index can be converted, using just a single
   search-and-replace operation, into the container for the whole
   standalone zip package.

 - The two major partitions of the html index can be labeled "Part
   1" and "Part 2" in a way that foreshadows their eventual
   publication as two separate documents.

 - The html index allows us to corral a whole zoo of disparate
   file formats (doc, pdf, xsd, xsl, xls, ...) into a single
   package that installs easily both on our web site and in the
   individual reviewer's hard drive and thereby gives us another
   three months in which to figure out how these things are
   actually going to be published as two printed documents.

 - This also allows us to leave the NDR document in exactly its
   current form -- a standalone printed document following the
   OASIS specification format that is simply pointed to from
   within the html index.  Pointing to this document from an html
   index shouldn't change its internal structure at all.

All of this assumes that we want both Part 1 and Part 2 to be
considered in parallel during the same review cycle.  This has
been my assumption for as long as we've been talking about this
review cycle.  If this is not our intention -- that is, if we want
two reviews on different schedules -- then of course most of what
I've been suggesting here doesn't apply.  If we want a single
review cycle -- which frankly is the only alternative that strikes
me as sane given the resources we have available to manage the
review -- then it seems to me logistically advisable to provide
all the pieces in one downloadable zip file.  For examples, see
the attachments to

   http://lists.oasis-open.org/archives/ubl-lcsc/200212/msg00066.html

Mechanically, this approach works very well.

However, Eve's comment above makes me realize that we probably
don't want to interject the "Intro," "Scope," "Definitions,"
etc. into Part 1 as I suggested earlier.  That really would screw
up the current organization of the NDR document.  So what I'm
suggesting now is that we leave the structure of the current
document formats (that is, the individual files) pretty much alone
and deal with figuring out editorial consistency as part of what
we (the chairs and editors) do during the three months that the
package is out for technical review.  Then the html index for the
review package would look something like this:

/=================================================================
| 
| H1 level: Review Package Title
| 
|    H2 level: Review Package Overview, including timeline,
|       contacts, mail lists, etc. (Tim or I can write this)
| 
|    H2 level: Universal Business Language Part 1: Naming and Design
|       Rules
| 
|       H3 level: Intro paragraph explaining the current role and
|          status of each of the subsidiary documents included in
|          this part of the package (Mark should write this)
| 
|       H3 level: Naming and Design Rules [pointer to .doc file]
| 
|       H3 level: Date and Time Representation [pointer to .doc
|          file] [perhaps, as Eve indicates, this piece should be
|          incorporated into the Naming and Design Rules file]
| 
|       H3 level: Code Lists (Informative[?]) [pointer to .pdf file]
| 
|       H3 level: Containership, Modeling, and Component Reuse
|          (Informative) [pointer to .doc file]
| 
|    H2 level: Universal Business Language Part 2: Library Content
| 
|       H3 level: Intro, Scope, etc.; Annexes (as previously
|          discussed)
| 
\=================================================================

Does this make sense to everyone?

Jon


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC