Re: Comments to OASIS BD-NDR

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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
>      abbreviations.
>
> - 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
>      values
>
>      Abbreviations for terms used in dictionary entry name information
>      values shall be taken from a controlled list of commonly-agreed
>      abbreviations.
>
> - 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.
https://www.avast.com/antivirus