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: Re: Draft responses to NDR comments from the public review

In regard to Patrick's comment:


There is an even more up-to-date version of XML Digital Signatures:


... and so I have updated it in my local copy of csd02wd02 to be the latest version 1.1 of that specification.

. . . . . . . Ken

At 2015-05-05 14:13 -0400, G. Ken Holman wrote:
I have found one missing change of a redirected link and so have changed that in my local copy.

I also did not mention under "normative markings" that the notes are implicitly non-normative.

In my local copy of the next csd02wd02 I have made these two edits.

. . . . . . . . Ken

At 2015-05-04 16:33 -0400, G. Ken Holman wrote:
Having received no feedback from TC members regarding the proposed disposition of comments for the NDR, I have incorporated the proposed dispositions into a working draft 01 of committee specification draft 02 of committee specification 01 here:


WE HAVE NOT AGREED ON THE PROPOSED DISPOSITIONS. I created the document to help committee members assess the impact of the proposed dispositions.

I have included as the net result of the lengthy discussion on the comment list with Patrick a declaration on the interpretation of normative markings. I propose we do not go through the effort of eliminating "hanging paragraphs" based on the small likelihood of ambiguity of having to cite such paragraphs at the beginning of sections. The discussion starts here:


... and addresses the comment here:


Otherwise, I think I've addressed all of the comments as I proposed in my post quoted below.

I invite TC members to review the proposed disposition of comments and the impact of those changes as I've implemented them in the putative result linked above. If you disagree with any of the proposed dispositions, or the way in which I have addressed the disposition, please speak up at your earliest convenience. I could very well have overlooked some detail or messed up.

I will address any points to be brought up on the fly so that when it comes time to vote on the proposed disposition of comments we can, at the same time, vote on the committee specification draft that addresses the comments.

I look forward to your feedback.

. . . . . . . . Ken

At 2015-04-28 16:40 -0400, G. Ken Holman wrote:
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]