Re: [emix-comment] two comments on CSD 01 / Public Review Draft 01

[Mary McRae <mary.mcrae@oasis-open.org>]

With regard to TC Process Requirements, it is my belief that the Namespace document serves that very purpose; incorporating actual URLs within the body of the document will only result in out-of-date links that can't be updated upon approval (that is, text that refers to cd01 will not be able to be updated to cd02 once the document has been approved at that level and generic URIs should not be used since it will potentially point to a version that is out of sync with the specific stage being reviewed). 

Regards,




Mary

On Nov 17, 2010, at 3:18 PM, Robin Cover wrote:

> With respect to the public review for EMIX Version 1.0
> CSD 01 [1]:
> 
> 1) 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]
> 
> 2) In the next spec revision, the file with name
>   "Emix Power Products.spp"
> 
> http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01-Schema/Emix%20Power%20Products.spp
>   needs to be fixed (and any URI references to the resource)
>   since SPACE character is not allowed:
> 
>   http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives-v1.0.html#nameCharacters
> 
> Cheers,
> 
> - Robin
> 
> [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).
> 
> -- 
> 
> Robin Cover
> OASIS, Director of Information Services
> Editor, Cover Pages and XML Daily Newslink
> Email: robin@oasis-open.org
> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> Cover Pages: http://xml.coverpages.org/
> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> Tel: +1 972-296-1783
> 
> 
> -- 
> This publicly archived list offers a means to provide input to the
> OASIS Energy Market Information Exchange TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: emix-comment-subscribe@lists.oasis-open.org
> Unsubscribe: emix-comment-unsubscribe@lists.oasis-open.org
> List help: emix-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/emix-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emix
>