Major I would suggest the specification be improved by
including in the principal prose document [2] a list
of the ten XML schemas (.xsd files) and related file
artifacts that are located in the 'Schema' directory.
I did not see any reference to these Schema (text)
files in the prose document, which mentions providing
"An XML Schema for Price and Product definition" and
clarification that "names are lowerCamelCase...as they
appear in the XML schemas." Readers using the prose
specification may want to know where to find the XML
schemas mentioned.
In fact, I think the intent of the TC Process is to
require that schema files be referenced by URI from
within a prose specification, e.g., URI references to
the individual schemas, or to a URI for a ZIP file or
directory. Sub TC Process Section "(7) Computer
Language Definitions" we are told that:
"All normative computer language definitions that
are part of the Work Product, such as XML instances,
schemas and Java(TM) code, including fragments of
such, must be well formed and valid...."[and]
"All normative computer language definitions must/should
be provided in separate plain text files... [and]
-
-
- "Each text file must be referenced from the Work Product" ***
-
In this context [4], "Work Product" seems to mean the
principal prose document (or documents) that is part of
a multi-file (multi-part) specification. [5]
[1] http://lists.oasis-open.org/archives/emix/201011/msg00083.html
Energy Market Information Exchange (EMIX) Version 1.0
Committee Specification Draft 01 /
Public Review Draft 01
15 November 2010
[2] prose document
http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01.html
http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01.doc
http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01.pdf
[3]
http://www.oasis-open.org/committees/process-2010-07-28.php#quality-formalLangDefns
[4] "Work Product"
In the 28 July 2010 (effective 15 October 2010) TC Process,
the term "Work Product" has more than one meaning: sometimes
it refers to the entire multi-file document entity (as a
whole), and in some cases, as here, it apparently means
"the principal prose document" which itself is part of
the whole Work Product entity.
In 2.18, "Work Product" clearly means the document entity
as a whole, despite parts:
(5) Multi-Part Work Products. A Work Product may be composed of
any number of files of different types, though any such
multi-part Work Product must have a single Work Product name
and version number. Irrespective of the number and status of
the constituent parts, the Work Product as a whole must be
approved by a single Work Product Ballot...
[5] In the assertion:
"Each text file must be referenced from the Work Product"
it cannot make sense to understand "the Work Product" as
a whole, viz, set of all the parts, as in
"Each [machine-readable] text file must be referenced from
the entire collection/set of files which constitute the
whole"
The text files ARE part of the set (whole), prima facie;
they need to be "referenced from" the prose document(s).