MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [ubl] To Comment "a.5" of 1.0 isses 20040721
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>"123 Standard Chartered Tower"</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.
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]