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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: Draft responses to NDR comments from the public review

Fellow UBL TC members,

I have reviewed the three comments received at the public comment email address and I offer the responses below as candidate dispositions for each.

. . . . . . Ken

Comment from Klaus-Dieter Naujok <tc154chair@mail-etc.net>

The UBL TC notes that ISO IS 15000-5:2014 post-dates the release of UBL 2.1, while the UN/CEFACT CCTS 2.01 that was designated ISO TS 15000-5:2005 remains current and has not been superceded. For these reasons, the reference in the NDR is not inappropriate.

Regarding the comment of the NDR possibly being in conflict with the revised ISO 15000-5:2014, the UBL TC notes this is unlikely given the commitment of TC154 to maintaining backwards compatibility to ISO TS 15000-5:2014 as documented in the following report:

(Page 14)
ISO TC154 is committed to upgrade the ISO TS15000-5 CCTS to a full IS standard and this work item has been approved on the basis that backwards compatibility with the current widely implemented TS version is maintained.

Comment from OASIS TC Administration <tc-admin@oasis-open.org>

The UBL TC acknowledges, with appreciation, the edits to be made to references used in the document.

Comments from the OASIS Technical Advisory Board

(a summary of JIRA tickets entered by TAB members)

- re: why not just an "information bundle"?
  - rejected
- because what is being specified is the creation of multiple validation artefacts (schemas) describing information bundle definitions, that constrain the information bundles (instances) ... the NDRs do not create information bundles - the introduction section makes the distinction in the first sentence of the third paragraph "the process by which the user data syntax constraint mechanisms are created from the abstract definition of the information bundles", which is consistent with referring to "information bundle definitions" in the conformance section
- re: Imprecise reference to normative content
  - agreed
- the text will be modified to read "where the words shall or required are used"
- re: conformance clause relying on examples
  - rejected
- reviewing the examples (entered as <note> elements) in the XML of the content there are zero occurrences of the words "must" or "required" in the prose of any of them
- re: normative text outside of the context of rules
  - rejected
- reviewing the XML, all rules are edited using the element <informaltable> and there no occurrences outside of a rule of the word "must" that is used to describe a constraint of the specification - the conformance clause refers to not violating "any rule or requirement expressed in normative sections of this specification" ... perhaps the phrase "or requirement expressed in normative sections" could safely be removed thus leaving the sentence to read "does not violate any rule of this specification", but I see no problem with leaving the sentence as it is - the list is not necessary in the conformance section as the list is simply all of the rules - Appendix C provides a summary list for convenience and reference into the specification

- re: the non-normative annex using the normative keywords
  - rejected
- Appendix C is an informative summary of only the verbatim introductory paragraph of the rules found in the normative text. For brevity and reference purposes, the complete text of the rules is not copied, only the introductory paragraph of each, so that the reader can determine which rule they may wish to examine more closely. That the verbatim citations happen to include a copy of normative keywords is not meant to convey additional requirements, as reinforced by the appendix being marked as "Non-Normative".

- re: 1.1.2
  - rejected
- in the definition of "naming and design rules" the local link behind the text "Core Component Technical Specification" is to the entry "Core Component Technical Specification", also in 1.1.2 - in the PDF in full-page mode the action leaves the impression the link is self-referential, however, when page scrolling is turned on in Acrobat the link moves the reader to a point just above the entry for "Core Component Technical Specification"
  - in the HTML this correct behaviour is more pronounced

- re: shaded background
  - rejected
- the shaded background is a formatting property only of markup examples and not of the prose: where an example is comprised only of markup (DCL06 as cited), the example appears to be fully shaded; where the example is comprised of both markup examples and prose (DCL08 is an example), the formatting properties can be distinguished

- re: heavy normative style
  - acknowledged but no changes proposed
- it is acknowledged that the algorithmic-sounding text appears arcane, but the pseudo-code in the associated example formulae is meant to illustrate the requirement in place of using a grammar to illustrate the requirement - can the person commenting recommend a particular grammar suited to expressing the conditional properties illustrated using the "IF" construct?

- re: GEN01 note
  - accepted
  - the note is suggested to be changed to:
    "A tool implementing collaborative interaction among project members
     responsible for the information being maintained would support such
     a process well."

- re: use of the word "optional"
  - rejected
- the use of the word "optional" in the phrase "that extension collection shall be optional and not repeated" is in reference to the cardinality "optional and not repeated" and is not the use of a keyword, thus the extension collection shall have the cardinality of optional and not repeated - the phrase "optional and not repeated" is typically recognized as a term of cardinality and so the extra verbiage need not be present

- use of the term "information bundle"
- as the use of "information bundle" is described in the Introduction as coming from ISO/IEC 14662 and represents the semantic abstract of what becomes an entire document - the term "component" is used in all of the UBL specifications (0.7, 1.0, 2.0 and 2.1) as a concise term for a single item in the information bundle - in the text cited by the reviewer, the UBL NDR is formally defining the use of the term "component" as being a member of the collection of components that describes the "information bundle" ... thus, the terms "information bundle" and "component" are not the same thing, and UBL has long used the term "component" and so defines it in the context of "information bundle" as defined by ISO/IEC 14662 - the text cited by the reviewer goes on to describe the component's type is dealt with in the NDR as being described by the BIEs of CCTS, and as the reviewer notes, the paragraph is consistently using the CCTS terminology as described in CCTS - the editors felt it useful to the reader to reiterate these basic definitions and abbreviations of CCTS so as not to require the reader to hunt down the definitions in the CCTS specification - there is no attempt to redefine the CCTS specification or shift the vocabulary: in the abstract a UBL document is an information bundle comprised of components defined by CCTS properties ... this abstraction is realized as an XML document ... the NDR governs the creation of validation artefacts of the XML documents as defined by the information bundle definitions defined as a collection of components

- the duplication in section 2.1 is noted, but the use of "shall" in paragraphs 2 and 3 are satisfying the statement in the first paragraph that there are always two steps present - that this is echoed in the rule is a consequence of the rule needing a normative keyword - so the uses outside of the rules are expository and the uses inside of the rules are normative - the editors will consider rewriting the expository text not to use the normative keywords: "There is always a process by which CCTS information regarding information bundles is managed." and "There is always a process in which user data validation artefacts are produced." ... then the normative keywords in the rules support the expository text.

- moving the extension concepts to be definitions is an acceptable suggestion
- the concept "XML document validation" supports multiple references in the document to validation artefacts and the checking of constraints on user data expressed in XML, while the normative references make no references to "validation" and some readers will be unfamiliar with the XSD abbreviation - given the third paragraph of section 2 adequately sets the context of XSD in the role of expressing document constraints, the editors can remove section 1.1.4 entirely

- so noted, with appreciation

- so noted, with appreciation

- so noted, with appreciation

- so noted, with appreciation

- so noted, with appreciation

- so noted, with appreciation

- accepted to move 11179 to the list of normative references (it is referenced in normatively in NDR section 1.1.2)

- the reviewers are asked clarify the details of this issue
- is it not true that, for example, clause 3.2 being labeled as non-normative confers the same non-normative status on descendent clauses? The editors can add the non-normative status to descendent clauses, but that seems redundant.

- so noted, with appreciation

Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/o/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |

This email has been checked for viruses by Avast antivirus software.

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