AW: [ubl] To Comment "a.5" of 1.0 isses 20040721

["Stuhec, Gunther" <gunther.stuhec@sap.com>]

Hello Mavis,

this is very confusing for me now. I compared the UBL 1.0 Library with the Naming and Design Rules "wd-ublndrsc-ndrdoc-V1pt0Draftp.doc", because this is the basis for my review and not the checklist.

Are this Naming and Design Rules didn't a normative part of UBL 1.0 anymore?

Kind regards,

	Gunther


-----Ursprüngliche Nachricht-----
Von: Mavis Cournane [mailto:mcournane@cognitran.com] 
Gesendet: Dienstag, 27. Juli 2004 09:14
An: Stuhec, Gunther
Cc: ubl@lists.oasis-open.org
Betreff: Re: [ubl] To Comment "a.5" of 1.0 isses 20040721


Gunther
in terms of the Documentation rules for the BBIE you are not looking at the 
rules in the NDR checklist - these are up to date. In the checklist there is 
no rule mandating UID - indeed, it is nolonger present. Mike Grimley and I 
recall that we had a discussion about UID and we all decided to remove it.

According to the checklist rules - Version - is optional.

Regards
Mavis

> Hello Jon,
> 
> some clarifications to the comment a.5 (The structure of the annotations are
> not similar to the definitions in chapter 3.7)
> 
> The chapter 3.7 defines the structure of annotation in rule DOC8 as
> follows:
> 
> <Documentation>[Dictionary Entry Name]</Documentation>
> 
> Also says chapter 3.7 from rule DOC1 - DOC7, how this "Dictionary Entry
> Names" must be represented as embedded documentation.
> 
> If I compare the following example to this rules, I can see some
> differences:
> 
> <xsd:annotation>
> 	<xsd:documentation>
> 		<ccts:Component>
> 			<ccts:ComponentType>BBIE</ccts:ComponentType>
> 			<ccts:DictionaryEntryName>Address Line. Line.
> Text</ccts:DictionaryEntryName>
> 			<ccts:Definition>An address line of unstructured text intended for 
use
> only by systems incapable of providing structured or fully structured
> addresses</ccts:Definition>
> 			<ccts:Cardinality>1..7</ccts:Cardinality>
> 			<ccts:ObjectClass>Address Line</ccts:ObjectClass>
> 			<ccts:PropertyTerm>Line</ccts:PropertyTerm>
> 			<ccts:RepresentationTerm>Text</ccts:RepresentationTerm>
> 			<ccts:DataType>Text. Type</ccts:DataType>
> 			<ccts:Examples>&quot;123 Standard Chartered Tower&quot;</ccts:
Examples>
> 		</ccts:Component>
> 	</xsd:documentation>
> </xsd:annotation>
> 
> The differences are:
> 	- the element "ccts:Component" is not defined as any rule in
> wd-ublndrsc-ndrdoc-V1pt0Draftp.doc
> 	- the prefix "ccts" is not defined as rule.
> 	- the BBIE needs the following information in the annotation (see rule
> DOC4):
> 		- Unique Identifier (mandatory) - is not represented!!!
> 		- CategoryCode (mandatory)- is named as "ComponentType" in the example
> above, but the code value is OK
> 		- Dictionary Entry Name (mandatory) - OK
> 		- Version (mandatory) - is not represented in the example above
> 		- Definition (mandatory) - OK
> 		- Cardinality (mandatory) - OK
> 		- QualifierTerm (optional) - other BBIEs have the element
> "PropertyTermQualifier", 
> 			like (<ccts:PropertyTermQualifier>Maximum</ccts:
PropertyTermQualifier>.
> 		- UsageRule (optional, repetitive) - not represented in any example
> 		- ConstraintLanguage (optional, repetitive) - not represented in any
> example
> 		- BusinessTerm (optional, repetitive) - other BBIE using 
> 			<ccts:AlternativeBusinessTerms>TREM card</ccts:
AlternativeBusinessTerms>,
> which 
> 			is not compliant to the CCTS, because it is defined only as
> "BusinessTerm".
> 		- Example (optional, repetitive) - The element name of the BBIE is
> "Examples" (Plural)
> 
> Also the BBIE has additional elements defined for: "ObjectClass",
> "PropertyTerm" and "RepresentationTerm", which are not described in rule
> DOC4.
> 
> Kind regards,
> 
> 	Gunther
> 
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the
> OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/ubl/members/
leave_workgroup.php.
>