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: Comments to OASIS BD-NDR

Here is another:

6) I think we can toss the NAM04 Namespace for schema annotations as a rule, since section 5.4 states there are no constraints regarding what annotation information may be added. Section 5.4 only states that it is good practice to document the schemas with the CCTS information, though not the runtime schemas because that would be a burden on them. Whether or not we get rid of NAM04, we can change the first words of the second paragraph of 5.4 "Provision is made in these NDR...", because annotations are a provision inherent in using XSD and not magically made possible by the NDR.

. . . . . . Ken

At 2016-05-04 20:03 -0400, G. Ken Holman wrote:
Fellow UBL TC members,

I've been implementing the revised Business Document NDRs that are currently under review and I've noted the following that I think should be addressed. I know this will trigger a short review, but I wouldn't be saying anything if I didn't think it was important.

1) - MOD02 currently reads:

    ABIE library contents

    The ABIE library shall not contain any Document ABIEs.

- as written, this is a tautology ... by definition a library has no document ABIEs. In fact it should read as I originally intended about referencing, not containment ... but it applies to both document and library ABIEs. I think this wording covers it:

    A Document ABIE shall not be referenced by any ASBIE.

What I didn't think we yet wanted to see is the embedding of a UBL document in another UBL document. Maybe in the future, but this was discussed at a teleconference a long while ago.

2) - COM04 currently reads:

     Controlled list of abbreviations in dictionary information values

     Abbreviations for terms used in dictionary information values
     shall be taken from a controlled list of commonly-agreed

- as written, this is too broad in that it encompasses those values that are commentary or are examples of data ... and we don't constrain data text values, only dictionary information name text values. I think this is better:

     Controlled list of abbreviations in dictionary entry name information

     Abbreviations for terms used in dictionary entry name information
     values shall be taken from a controlled list of commonly-agreed

- this is distinguished from COM03 which is related to the element name values
- we still need the distinction because, for example, we don't allow "ID" in a dictionary entry name information value but we do allow it as an abbreviation in the element name

3) - there are rules for a component type of ABIE, BBIE and ASBIE
- there is no rule that prohibits a component type being an invalid value
- should we add one?

4) - the equation for the dictionary entry name for a BBIE is correct, but it is not presented on the page the same way as it is for an ASBIE; the ASBIE is presented in a way that might be better interpreted by someone unfamiliar with XPath - I recommend the BBIE presentation of the equation be changed to mimic that of the ASBIE (editorial only)

5) - rules COM11 and COM14 cannot be programmatically tested as they are subjective to the needs of the user

   COM11 Use of the singular form in names
   All information items contributing to a component's dictionary entry
   name shall be in the singular form unless the concept itself is plural.

   COM14 ABIE organization
   Every BIE for a given ABIE shall be organized in the semantic model
   in the order the BIEs are to be expressed in Open-edi user data.

- I propose removing them from the group of COM rules and creating a new group of rules USR01 and USR02

. . . . . . . . Ken

Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
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]