Docstoc

0p70 Comments UBL 0p70 Comments Last Updated 18 Jul 2010 Last Updated By Anne Hendry Comment ID Comment Date

Document Sample
0p70 Comments UBL 0p70 Comments Last Updated 18 Jul 2010 Last Updated By Anne Hendry Comment ID Comment Date Powered By Docstoc
					                                         0p70 Comments

UBL 0p70
Comments
Last Updated:            18. Jul. 2010
Last Updated By:         Anne Hendry


Comment ID               Comment Date
(boldface number
corresponds to archive
directory name)

1.1                      28. Jan. 2003




1.2                      28. Jan. 2003


1.3                      28. Jan. 2003




2.1                      28. Jan. 2003




                                            Page 1
                      0p70 Comments

3.1   28. Jan. 2003




3.2   28. Jan. 2003




3.3   28. Jan. 2003




3.4   28. Jan. 2003




3.5   28. Jan. 2003




3.6   28. Jan. 2003




3.7   28. Jan. 2003




                         Page 2
                      0p70 Comments

3.8   28. Jan. 2003




4.1   29. Jan. 2003




5.1   3. Feb. 2003




5.2   3. Feb. 2003




5.3   3. Feb. 2003




5.4   3. Feb. 2003




                         Page 3
                     0p70 Comments

5.5   3. Feb. 2003




5.6   3. Feb. 2003




5.7   3. Feb. 2003




5.8   3. Feb. 2003




5.9   3. Feb. 2003




6.1   4. Feb. 2003




                        Page 4
                      0p70 Comments

6.2   4. Feb. 2003


6.3   4. Feb. 2003


7.1   9. Feb. 2003




7.2   9. Feb. 2003




7.3   9. Feb. 2003




8.1   10. Feb. 2003




9.1   11. Feb. 2003

9.2   11. Feb. 2003




9.3   11. Feb. 2003


9.4   11. Feb. 2003



9.5   11. Feb. 2003




                         Page 5
                       0p70 Comments

9.6    11. Feb. 2003




9.7    11. Feb. 2003


9.8    11. Feb. 2003




9.9    11. Feb. 2003




10.1   28. Feb. 2003




11.1   24. Feb. 2003




11.2   24. Feb. 2003




12.1   25. Feb. 2003




13.1   25. Feb. 2003




14.1   25. Feb. 2003



15.1   25. Feb. 2003




                          Page 6
                       0p70 Comments


16.1   25. Feb. 2003




17.1   25. Mar. 2003




                          Page 7
                       0p70 Comments

18.1   27. Feb. 2003




19.1   27. Feb. 2003




20.1   27. Feb. 2003




                          Page 8
                       0p70 Comments

c.1    27. Feb. 2003




22.1   28. Feb. 2003




                          Page 9
                      0p70 Comments

23.1   3. Mar. 2003




24.1   3. Mar. 2003




24.2   3. Mar. 2003




                         Page 10
                                            0p70 Comments

24.3                         3. Mar. 2003




24.4                         3. Mar. 2003




Follwing comments are
not yet filed on the OASIS
server.

a.1                          7. Mar. 2003


a.2                          7. Mar. 2003


a.3                          7. Mar. 2003



b.1                          4. Mar. 2003




b.2                          4. Mar. 2003




                                               Page 11
                      0p70 Comments

d.1   5. Mar. 2003




d.2   5. Mar. 2003




d.3   5. Mar. 2003




d.4   5. Mar. 2003




d.5   5. Mar. 2003




e.1   11. Mar. 2003




                         Page 12
                      0p70 Comments

e.2   11. Mar. 2003




e.3   11. Mar. 2003




e.4   11. Mar. 2003


f.1   10. Mar. 2003


f.2   10. Mar. 2003




                         Page 13
                       0p70 Comments

f.3    10. Mar. 2003




f.4    10. Mar. 2003

f.5    10. Mar. 2003

f.6    10. Mar. 2003



f.7    10. Mar. 2003




f.8    10. Mar. 2003


f.9    10. Mar. 2003



f.10   10. Mar. 2003




f.11   10. Mar. 2003




g.1    27. Feb. 2003

g.2    27. Feb. 2003

g.3    27. Feb. 2003


g.4    27. Feb. 2003

g.5    27. Feb. 2003

g.6    27. Feb. 2003




                          Page 14
                       0p70 Comments

g.7    27. Feb. 2003

g.8    27. Feb. 2003

g.9    27. Feb. 2003

g.10   27. Feb. 2003

g.11   27. Feb. 2003

g.12   27. Feb. 2003

g.13   27. Feb. 2003

g.14   27. Feb. 2003

g.15   27. Feb. 2003

g.16   27. Feb. 2003

g.17   27. Feb. 2003

g.18   27. Feb. 2003

g.19   27. Feb. 2003

g.20   27. Feb. 2003

g.21   27. Feb. 2003

g.22   27. Feb. 2003

g.23   27. Feb. 2003


h.1    20. Mar. 2003

h.2    20. Mar. 2003



h.3    20. Mar. 2003


h.4    20. Mar. 2003

h.5    20. Mar. 2003

h.6    20. Mar. 2003




                          Page 15
                      0p70 Comments

h.7   20. Mar. 2003




i.1   24. Mar. 2003




i.2   24. Mar. 2003




j.1   15. Mar. 2003




                         Page 16
                      0p70 Comments

j.2   15. Mar. 2003




j.3   15. Mar. 2003




                         Page 17
                         0p70 Comments




Reviewer Name                            UBL Artifact Reviewed
Reviewer Contact Info



Robert Shmit                             Comment Form
robert_shmit@yahoo.com




Robert Shmit                             Batch script for schema creation
robert_shmit@yahoo.com

Robert Shmit                             Data Model spreadsheets
robert_shmit@yahoo.com


Ed Day                                   ASN Spec
eday@obj-sys.com




                            Page 18
                             0p70 Comments

Garret Minakawa                              UBL Library
garret.minakawa@oracle.com




Garret Minakawa                              UBL Library
garret.minakawa@oracle.com




Garret Minakawa                              All
garret.minakawa@oracle.com


Garret Minakawa                              All
garret.minakawa@oracle.com




Garret Minakawa                              All CCD*s:
garret.minakawa@oracle.com                   CCD000[661,662,901]



Garret Minakawa                              All *PartyType
garret.minakawa@oracle.com                   UBL000[089,126,202,228,551]


Garret Minakawa                              All *PartyType
garret.minakawa@oracle.com                   UBL000[089,126,202,228,551]



                                Page 19
                                    0p70 Comments

Garret Minakawa                                     All *PartyType
garret.minakawa@oracle.com                          UBL000[089,126,202,228,551]



Stephen Cowe                                        Purchase Order
stephen.cowe@sun.com




Vilhelm Bjermeland                                  Not given
vil@s2labs.com




Vilhelm Bjermeland                                  Not given
vil@s2labs.com




Vilhelm Bjermeland vil@s2labs.com                   Not given




Vilhelm Bjermeland vil@s2labs.com                   Not given




                                       Page 20
                                    0p70 Comments

Vilhelm Bjermeland vil@s2labs.com                   Not given




Vilhelm Bjermeland vil@s2labs.com                   Not given




Vilhelm Bjermeland                                  Not given
vil@s2labs.com




Vilhelm Bjermeland                                  Not given
vil@s2labs.com




Vilhelm Bjermeland                                  Not given
vil@s2labs.com




Ed Mooney                                           UBL000014, UBL000362
ed.mooney@sun.com



                                       Page 21
                             0p70 Comments

Ed Mooney                                    UBL000191, UBL000238
ed.mooney@sun.com                            [UBL000481]*

Ed Mooney                                    UBL000192, UBL000239
ed.mooney@sun.com

Calvin Smith                                 Various
calvins@sims.berkeley.edu
Patrick Garvey
pgarvey@sims.berkeley.edu

Calvin Smith                                 Various
calvins@sims.berkeley.edu
Patrick Garvey
pgarvey@sims.berkeley.edu




Calvin Smith                                 Various
calvins@sims.berkeley.edu
Patrick Garvey
pgarvey@sims.berkeley.edu


Bob Miller                                   Documentation: UBL Document Schemas
robert.miller@gxs.com



Garret Minakawa                              Address
garret.minakawa@oracle.com
Garret Minakawa                              Address
garret.minakawa@oracle.com




Garret Minakawa                              Address
garret.minakawa@oracle.com

Garret Minakawa                              Address
garret.minakawa@oracle.com


Garret Minakawa                              Address
garret.minakawa@oracle.com



                                Page 22
                             0p70 Comments

Garret Minakawa                              Address
garret.minakawa@oracle.com



Garret Minakawa                              Contact
garret.minakawa@oracle.com

Garret Minakawa                              Contact
garret.minakawa@oracle.com


Garret Minakawa                              Contact
garret.minakawa@oracle.com



Becky Randall                                Purchase Order
Becky.Randall@sun.com


Chin Chee-Kai                                Samples (Joinery and Office Supply)
cheekai@softml.net


Chin Chee-Kai                                Samples (general)
cheekai@softml.net




Chin Chee-Kai                                Order Response Speadsheet
cheekai@softml.net



Chin Chee-Kai                                Spreadsheets (general)
cheekai@softml.net



Chin Chee-Kai                                Receipt Advice Spreadsheet
cheekai@softml.net


Chin Chee-Kai                                Order Cancellation
cheekai@softml.net




                                Page 23
                     0p70 Comments


Chin Chee-Kai                        Order Schema
cheekai@softml.net




Dan Vint                             Schemas
dvint@acord.org




                        Page 24
                                0p70 Comments

David Burdett                                   UBL Library
david.Burdett@commerceone.com




David Burdett                                   UBL Library
david.Burdett@commerceone.com




David Burdett                                   UBL Library
david.Burdett@commerceone.com




                                   Page 25
                                0p70 Comments

David Burdett                                   Order
david.Burdett@commerceone.com




Pankaj Patel                                    UBL Library
pankaj.patel@convergys.com




                                   Page 26
                            0p70 Comments

Anders Rundgren                             UBL Library
anders.rundgren@telia.com




Jörg Walther                                UBL000089 and other
walther@gefeg.com




Jörg Walther                                UBL000089 and other
walther@gefeg.com




                               Page 27
                                            0p70 Comments

Jörg Walther                                                UBL000002 and other
walther@gefeg.com


Jörg Walther                                                UBL000009 and other
walther@gefeg.com




Fabio Bruzzone                                              UBL000191, UBL000238
f.bruzzone@infologistica.it
Emiliano Grigis e.grigis@infologistica.it
Fabio Bruzzone                                              UBL000192, UBL000239
f.bruzzone@infologistica.it
Emiliano Grigis e.grigis@infologistica.it
Fabio Bruzzone                                              UBL000014, UBL000362
f.bruzzone@infologistica.it
Emiliano Grigis e.grigis@infologistica.it

Bill Burcham                                                Order
Bill_Burcham@stercomm.com




Bill Burcham
Bill_Burcham@stercomm.com




                                               Page 28
                                         0p70 Comments

CEN/ISSS/EEG1 Trade                                        0p70
Eurofer: Freddy De Vos (F.de_vos@eurofer.be)
EAN.UCC: Dany De Zutter (dezutter@ean-int.org)
Solvay/CIDX Europe: Raymond Betz (raymond.betz@solvay.com)
MK Enterprises: Mounir el-Khoury (mounir.el-khoury@pi.be)


CEN/ISSS/EEG1 Trade                                        0p70
Eurofer: Freddy De Vos (F.de_vos@eurofer.be)
EAN.UCC: Dany De Zutter (dezutter@ean-int.org)
Solvay/CIDX Europe: Raymond Betz (raymond.betz@solvay.com)
MK Enterprises: Mounir el-Khoury (mounir.el-khoury@pi.be)

CEN/ISSS/EEG1 Trade                                        0p70
Eurofer: Freddy De Vos (F.de_vos@eurofer.be)
EAN.UCC: Dany De Zutter (dezutter@ean-int.org)
Solvay/CIDX Europe: Raymond Betz (raymond.betz@solvay.com)
MK Enterprises: Mounir el-Khoury (mounir.el-khoury@pi.be)

CEN/ISSS/EEG1 Trade                                        0p70
Eurofer: Freddy De Vos (F.de_vos@eurofer.be)
EAN.UCC: Dany De Zutter (dezutter@ean-int.org)
Solvay/CIDX Europe: Raymond Betz (raymond.betz@solvay.com)
MK Enterprises: Mounir el-Khoury (mounir.el-khoury@pi.be)

CEN/ISSS/EEG1 Trade                                        0p70
Eurofer: Freddy De Vos (F.de_vos@eurofer.be)
EAN.UCC: Dany De Zutter (dezutter@ean-int.org)
Solvay/CIDX Europe: Raymond Betz (raymond.betz@solvay.com)
MK Enterprises: Mounir el-Khoury (mounir.el-khoury@pi.be)


Chin Chee-Kai                                             0p70
cheekai@softml.net




                                             Page 29
                     0p70 Comments

Chin Chee-Kai                        0p70
cheekai@softml.net




Chin Chee-Kai                        0p70
cheekai@softml.net




Chin Chee-Kai                        0p70
cheekai@softml.net

Chin Chee-Kai                        All
cheekai@softml.net

Chin Chee-Kai
cheekai@softml.net




                        Page 30
                                         0p70 Comments

Chin Chee-Kai
cheekai@softml.net




Chin Chee-Kai
cheekai@softml.net
Chin Chee-Kai
cheekai@softml.net
Chin Chee-Kai
cheekai@softml.net


Chin Chee-Kai
cheekai@softml.net


Chin Chee-Kai
cheekai@softml.net

Chin Chee-Kai
cheekai@softml.net


Chin Chee-Kai
cheekai@softml.net



Chin Chee-Kai
cheekai@softml.net



ACORD: Nigel Wooden                                      All
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 2
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 11
Nigel.wooden@spangraph.freeserve.co.uk

ACORD: Nigel Wooden                                      Lines 17 and 18
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Lines 20, 21, 1nd 22
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Lines 23 and 24
Nigel.wooden@spangraph.freeserve.co.uk



                                            Page 31
                                         0p70 Comments

ACORD: Nigel Wooden                                      Line 29
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 52
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 137
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 140
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 142
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 201
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 205
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 219
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Lines 220 – 224
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 261
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Lines 269 – 275
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 296
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Lines 364 – 366
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 617
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 618
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 619
Nigel.wooden@spangraph.freeserve.co.uk
ACORD: Nigel Wooden                                      Line 646
Nigel.wooden@spangraph.freeserve.co.uk

Chin Chee-Kai
cheekai@softml.net
Chin Chee-Kai
cheekai@softml.net


Chin Chee-Kai                                            All schemas
cheekai@softml.net

Chin Chee-Kai
cheekai@softml.net
Chin Chee-Kai                                            UBL000086, UBL000109, UBL000346,
cheekai@softml.net                                       UBL000560, UBL000603
Chin Chee-Kai                                            UBL000403
cheekai@softml.net




                                            Page 32
                         0p70 Comments

Chin Chee-Kai                            All schemas
cheekai@softml.net




Jeffrey P. Silverstone
jps@his.com




Jeffrey P. Silverstone
jps@his.com




Chin Chee-Kai                            All schemas and spreadsheets
cheekai@softml.net




                            Page 33
                     0p70 Comments

Chin Chee-Kai                        All schemas and spreadsheets
cheekai@softml.net




Chin Chee-Kai                        All schemas and spreadsheets
cheekai@softml.net




                        Page 34
                           0p70 Comments




File Name                     File Version




0p70/UBL_Comment-0p1.rtf      1. Jan. 2003




0p70/bin/ubl.bat              0p70


0p70/xls/*.xls                0p70



0p70/asn/asn1spec.html        0p70




                              Page 35
                                         0p70 Comments

All                                         0p70




All                                         0p70




0p70/ubl/CoreComponentTypes.xsd             18. Jan. 2003



0p70/ubl/CoreComponentTypes.xsd             18. Jan. 2003




0p70/ubl/CoreComponentTypes.xsd             18. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




                                            Page 36
                                         0p70 Comments

0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




n/a                                         n/a




?                                           ?




?                                           ?




?                                           ?




?                                           ?




                                            Page 37
                                         0p70 Comments

?                                           ?




?                                           ?




?                                           ?




?                                           ?




?                                           ?




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




                                            Page 38
                                         0p70 Comments

0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003


0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003


0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




0p70/ubl/CoreComponentTypes.xsd             18. Jan. 2003




0p70/index.html                             0p70




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003

0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003


0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003



0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




                                            Page 39
                                              0p70 Comments

0p70/xsd/UBL_Library_0p70_Reusable.xsd           21. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd           21. Jan. 2003


0p70/xsd/UBL_Library_0p70_Reusable.xsd           21. Jan. 2003



0p70/xsd/UBL_Library_0p70_Reusable.xsd           21. Jan. 2003




n/a                                              n/a



n/a                                              0p70



n/a                                              0p70




0p70/xls/UBL_Library_0p70_OrderResponse.xls      0p70




All                                              0p70




0p70/xls/UBL_Library_Op70_ReceiptAdvice.xls      0p70



0p70/xsd/UBL_Library_0p70_OrderCancellation.xs 0p70
d




                                                 Page 40
                                      0p70 Comments


0p70/xsd/UBL_Library_0p70_Order.xsd      0p70




All                                      0p70




                                         Page 41
      0p70 Comments

All      0p70




All      0p70




All      0p70




         Page 42
                                      0p70 Comments

0p70/xsd/UBL_Library_0p70_Order.xsd      0p70




All                                      0p70




                                         Page 43
                                         0p70 Comments

All                                         0p70




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




                                            Page 44
                                         0p70 Comments

0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003



0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003


0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003


0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003



0p70/xsd/UBL_Library_0p70_Order.xsd         0p70




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003




                                            Page 45
                                         0p70 Comments

All                                         0p70




All                                         0p70




All                                         0p70




All                                         0p70




All                                         0p70




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003
0p70/xls/UBL_Library_0p70_Reusable.xls




                                            Page 46
                                         0p70 Comments

0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003
0p70/xls/UBL_Library_0p70_Reusable.xls




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003
0p70/xls/UBL_Library_0p70_Reusable.xls




0p70/xsd/UBL_Library_0p70_Reusable.xsd      21. Jan. 2003
0p70/xls/UBL_Library_0p70_Reusable.xls

All XSD files                               0p70


0p70/xsd/UBL_Library_0p70_DespatchAdvice.xsd 0p70
0p70/xlsUBL_Library_0p70_DespatchAdvice.xls




                                            Page 47
                                         0p70 Comments

0p70/xls/UBL_Library_0p70_Invoice.xls         0p70




0p70/xsd/UBL_Library_0p70_Reusable.xsd       0p70
0p70/xls/UBL_Library_0p70_Reusable.xls
0p70/xsd/UBL_Library_0p70_DespatchAdvice.xsd 0p70

0p70/xsd/UBL_Library_0p70_Reusable.xsd and    0p70
all schemas


All schemas                                   0p70




0p70/xsd/UBL_Library_0p70_Order.xls         0p70
0p70/xsd/UBL_Library_0p70_OrderResponse.xsd

0p70/xsd/UBL_Library_Op70_ReceiptAdvice.xls   0p70
0p70/xsd/UBL_Library_Op70_ReceiptAdvice.xsd


All schemas                                   0p70




All schemas                                   0p70




0p70/xls/UBL_Library_0p70_Reusable.xls        0p70

0p70/xls/UBL_Library_0p70_Reusable.xls        0p70

0p70/xls/UBL_Library_0p70_Reusable.xls        0p70


0p70/xls/UBL_Library_0p70_Reusable.xls        0p70

0p70/xls/UBL_Library_0p70_Reusable.xls        0p70

0p70/xls/UBL_Library_0p70_Reusable.xls        0p70




                                              Page 48
                                         0p70 Comments

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70


0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xls      0p70



*.xsd                                       0p70


0p70/xls/UBL_Library_0p70_Reusable.xls      0p70

0p70/xls/UBL_Library_0p70_Reusable.xsd      0p70

0p70/xls/UBL_Library_0p70_Reusable.xsd      0p70




                                            Page 49
                                         0p70 Comments

*.xsd                                       0p70




0p70/xsd/UBL_Library_0p70_Order.xsd         0p70
0p70/xsd/UBL_Library_0p70_Reusable.xsd
0p70/xsd/CoreComponentTypes.xsd




0p70/xsd/UBL_Library_0p70_Order.xsd         0p70
0p70/xsd/UBL_Library_0p70_Reusable.xsd
0p70/xsd/CoreComponentTypes.xsd




0p70/xsd/*.xsd                              0p70




                                            Page 50
                 0p70 Comments

0p70/xsd/*.xsd      0p70




0p70/xsd/*.xsd      0p70




                    Page 51
                                                 0p70 Comments




Comment




I use a Linix machine and can not view all UBL information (this document is edited using OpenOffice). UBL is
Microsoft platform specific since it uses Microsoft spreadsheet formats and .bat files. Is the plan to continue
with these vendor-spefic formats?




I use a Linix machine and can not view all UBL information (this document is edited using OpenOffice). UBL is
Microsoft platform specific since it uses Microsoft spreadsheet formats and .bat files. Is the plan to continue
with these vendor-spefic formats?
I use a Linix machine and can not view all UBL information (this document is edited using OpenOffice). UBL is
Microsoft platform specific since it uses Microsoft spreadsheet formats and .bat files. Is the plan to continue
with these vendor-spefic formats?

My comment is about the attached ASN.1 specification to this document. I would like to use it to build some
sample applications, but I can't compile the specification because an import file - XSD.asn - is missing. Is this
defect going to be corrected so that the spec is usable?




                                                     Page 52
                                                 0p70 Comments

Relationship to CCTS:
I am having a hard time seeing how UBL v0p70 can/will be reverse engineered into CCTS v1.90 to create
BCCs/ACCs/ASCCs and Data Types. Since UBL jumps directly from CCTs to BIEs, it is difficult to see the
relationship between BIE, CC, Data Type, and CCT.

Annex A of the Public Review Package refers to de-contextualized BIEs. It appears that de-contextualized BIEs
and CCs are the same thing. Can a BIE and a CC have exactly the same name and schema definition?

Is the Normalised Model intended to be the UBL set of Core Components? If so, shouldn‟t this be represented
in a separate Core Components schema file?

I am also not clear about how UBL intends to implement CCTS Data Types. Based on my understanding, all
BIEs must be based on a CC and all BCC or BBIE properties must be based on a Data Type.
Extension Methodology:
Although details are due in a future release, I‟m wondering if the entire concept of extensibility fits into the CCTS
model. In Section 6.2.1 of CCTS v1.90 it states:
“The Context mechanism provides a full semantic qualification for the Core Component used in a Business
Process … Qualification is to be interpreted as specialization as defined in UML. Qualification narrows the
semantic concept to a more specific one. The structure of qualified Business Information Entities may be a
subset (but never a superset) of the structure of the (unqualified) Business Information Entities or Core
Components upon which they are based.”
I‟m not sure if I necessarily agree with this statement but it seems to be fairly clear about extensions to BIEs or
Ccs.
As I look back on these comments, I guess the overriding question is, “How strictly does UBL want to conform
to CCTS?”. The UBL charter does not explicitly say anything about CCTS conformance but I have been
operating under the assumption that everything produced by UBL will not violate any of the rules or guidelines in
CCTS v1.90.

commonAttributes Attribute Group:
Since these attributes are UBL-specific and not part of CCTS v1.90, I recommend that they be removed from
CoreComponentTypes.xsd and placed in a UBL-specific extension to CoreComponentTypes.xsd.

Supplementary Components:
UBL has elected to implement only a subset of the available Supplementary Components. This does not violate
CCTS guidelines but it may cause difficulties for other vocabularies that want to leverage a common base
schema for Core Component Types. I recommend that all available Supplementary Components be
implemented as attributes in CoreComponentTypes.xsd. UBL restrictions of these Supplementary Components
can be implemented as Data Types or at the CC or BIE level.


DateType, TimeType, PercentType, NameType, ElectronicAddressType:
What does the prefix “CCD” mean when used as “id=CCD000661”? Does it stand for Data Type? If so, I would
suggest that all Data Types be placed into a separate DataTypes.xsd schema file instead of mixing them with
CCTS Core Component Types.

PartyType. This schema contains definitions for BuyerPartyType, ContactPartyType, DestinationPartyType,
FreightForwarderPartyType, and SellerPartyType. There is no schema definition, however, for PartyType. This
seems inconsistent since there are schema definitions for AddressType and ContactType, both of which appear
to be similar to PartyType in their usage.

PartyId. A single party can have multiple identifiers depending on on who that party is doing business with.
There may be an internal identifier your application uses to identify the party, there may be an external identifier
that the party uses to refer to themselves, and there may be an industry identifier such as DUNS or SCAC. The
current definition allows for only one party identifier.


                                                      Page 53
                                                 0p70 Comments

Party Relationships. There is no mechanism to reflect the relationship between parties or to indicate how an
individual party fits into a larger organizational structure. For large corporations, it would be common to have
multiple party records for the same company. There should be a way to associate these multiple party records.



I've not had a chance to look at the detail of the standards, but a very quick question regarding the business
process/message flow for the buyer/seller procurement cycle. Q) Why no Purchase Order change? Reading
the web-site it states that, for a buyer initiated change, the buyermust first cancel the order and then raise a new
order. This is not a feasible business practice for many organisations and/or ERP systems. Will a buyer
initiated PO Change standard be coming out at a later revision of these standards or are you hoping that
someone will take the core components and create one for submission? If you could let me know about this
asap, we will start looking at the detail and try to get more comments back to you.

Invoice line references order line. Should this not also reference the order header number? One
invoice/shipment can come from multiple orders so if just referencing the order line you may not know exactly
which one it is. Unless it is required to only reference one order on one invoice.




Should it not be possible to be more specific on a line item on an invoice such as LPN/Serial number? To me it
would make sense to have the ability to not only be able to identify the item and quantity but more specifically
the exact box which was invoiced.




Tax issues - maybe I have not seen this yet but it is possible to have both tax exemptions and exceptions at the
line level for a specific shipment/invoice/order. All tax related charges should be able to be kept at line level.
Tax amount should be able to be stored at the line level and not only header level.




Item measurements/attributes. It should be possible to specify the item using many different values/attributes
(Speed, size, weight etc.). It should be possible to create as many specifications for an item as needed. I may
have missed this but I don't see how that is possible right now.




                                                     Page 54
                                                 0p70 Comments

Sub-line. I guess you have decided to take this out, but how would it be possible to send through an order for
multiple computers with different specifications (memory, HD size etc.) using this standard? You need some
sort of way to group order lines. If not you would be required to send separate orders for each computer which
may not be ideal since you want to be able to use the same reference (PO number) as your ERP system.




ID descriptions - many places are ID's sent across (Send From_Address.Identification etc.). Since this is a
transmission between two trading partners would it not be good to always specify who issued the specific ID
(DUNS, Seller, Buyer, etc.). If the order just reference some ID how do you know exactly what kind of ID (who
controls/issued the number).




Multi-quantity reference. My background is from semiconductors so it may be a little unique but I think the
concept would also be relevant elsewhere. When selling between plants we need to not only reference number
of die sent but also how many wafers and in some cases each individual wafer with number of dies (which
varies based on yield). Should it not be possible to have other ways to reference a specific line instead of just
pure quantity. (one wafer has multiple dies depending on how many passed testing).




Referencing contact - should it not be possible to have multiple phone numbers? I would also suggest a
possibility for other multiple contact types. With more types/ways of communicating we should be able to send
these new types without having to change the standard. Cell phone, pager, IM ID and others are possible. I
would like to see it so you could create specific custom contact types which only you use. I am sure in the
future there will be many new contact references needed.




Payment terms - are the different scenarios thought out. Is it possible to specify the due date at a specific date
(day of future month) etc. If you want I can put together a small list of unique payment terms which should be
covered.




Global elements have names differing only by case:
ServiceLevelCode, ServicelevelCode.



                                                     Page 55
                                                0p70 Comments

Global elements have names differing only by case:
ToFollowQuantity, TofollowQuantity.
*[Ed. Note: In addition, there are two IDs for ToFollowQuantity]
Global elements have names differing only by case:
ToFollowReason, TofollowReason.

Inconsistencies in uncontextualized BIEs:
There are apparent inconsistencies in uncontextualized BIEs. For example, there is an uncontextualized
AddressType and ContactType, in addition to the contextualized types, but there is no uncontextualized
PartyType, as there was in previous releases. How does UBL envision a UBL user creating, for example, a
NotaryParty, given that there is no suitable UBL (uncontextualized) Party Type from which to derive.
Uncontextualized BIEs are not used in implementation:
Although there is an uncontextualized AddressType and ContactType, they are not utilized by the types that add
context, such as BuyerAddressType and BuyerContactType – that is, there is no type derivation using the
uncontextualized type as a base type, and even though there is commonality between BuyerContact and
ShippingContact, and there is a relationship between the two in the spreadsheet, the implementation in XSD
does not represent this – apart from the documentation in the XSD which states that the Object Class Term of
both is Contact. Why did UBL choose not to use extension, as outlined in the XML 2002 paper of Gregory and
Gutentag, XSD Type Derivation and the UBL Context? For example, JurisdictionAddressType and
DeliverToAddressType have the same content, yet this is not represented in the XSD through derivation from a
common base type. This would create a stronger link between the various Address types, which seems to be
the case in the spreadsheet and is implicit in the documentation of the various types, which state that both have
the same objectClassTerm.
Another concern with the new scheme (without type derivation) is stylesheet processing when type aware tools
Elimination of Core Components simpleTypes:
With the elimination of all the Core Components simpleTypes, such as identifierContentType (0p64), how
should extenders of UBL define attributes, given that attributes may not be of a complexType. It seems that one
either has to not use attributes, or not use any UBL types or types derived from UBL for attributes. Which, if
any, of these solutions does UBL recommend?

Section 7.1 states that the XML Schemas are the normative reference for this set of specifications. But other
content in these specifications suggest that the XML Schemas (and some other representations) are
(systematically) derived. Should not the normative reference be to the original material from which the
Schemas derive, and not to the Schemas, which appear to represent only a subset of the parent material?

Address. Other XML vocabularies use “Postal Address” instead of “Address”. Semantically, these two terms
seem to be pretty close but given a preference, I think Postal Address is more descriptive than Address.
Address Line – Structured vs. Unstructured. UBL has taken the position of capturing each component of an
address line as a separate element (e.g. Building, HouseName, HouseNumber, Street, Floor, etc.). This is
consistent with most enterprise data models and can be considered as industry best practice. However, there
is also wide implementation of an “unstructured” address line format that consists of Address Line 1 and
Address Line 2. Both formats appear to be widely used and perfectly valid as a generic address definition. I
would recommend the use of xsd:choice to allow either an unstructured address line or a structured address
line.
Mapping to State, Province, County. Many enterprise applications store State, Province, State/Province, and
County as part of an address. It is not clear how these data elements map to the UBL address model.

Country. I do not understand the purpose of CountryType. The Country element is based on type CountryType
and CountryType contains one child element (Code). Wouldn‟t it be more reasonable to implement a
CountryCode element based on type Code and accomplish the same thing?

Addressee, c/o, Attn. If you think of Address/PostalAddress as an address on an envelope, you would also
expect to see addressee information as part of the address definition. This is not currently part of the UBL
address definition.


                                                     Page 56
                                                0p70 Comments

Delivery vs. Internal Routing Information. Some information in the UBL Address Type is required by postal
authorities (e.g. U.S. Postal Service) to successfully deliver a piece of mail. Examples would include
PostalZone, Country, City. Other information such as InouseMail, Department, and Room are solely used for
internal routing. Should internal routing information be contained in an Address type or some other type such
as Location?
Multiple Contact Numbers. The current UBL Contact definition contains ID, Name, Phone, Fax, E-Mail but does
not provide for Multiple Contact Numbers. A given contact may have multiple phone numbers or e-mails or fax
numbers. The UBL model needs to allow multiple numbers for each contact method.
Other Contact Methods. The current UBL Contact definition contains ID, Name, Phone, Fax, E-Mail but does
not provide for Other Contact Methods. The current model restricts the list of contact methods to phone, fax, or
e-mail. It is very possible that other contact methods such as IM (Instant Messenger) or Pager may be
required. The UBL model does not allow for existing (and future) contact methods.
Contact Preferences. The current UBL Contact definition contains ID, Name, Phone, Fax, E-Mail but does not
provide for Contact Preferences. It is a common business practice to capture contact preferences such as e-
mail is preferred over fax. It may also be necessary to identify a preferred telephone number from a list of
telephone numbers.

I don't see Order Change, Iinstead I see Order Cancellation. I was curious if/when there will be an Order
Change schema?


Should there be an additional sample document of document type "ReceiptAdvice" sent by Buyer to Seller
inserted before "Invoice"? Normally, the receiving of a "ReceiptAdvice" would signify an "cargo-received-well"
signal and trigger an Invoice to be generated and sent by Seller.

I think it is very good to have samples in the fs/ directory to show how the source is being transformed into
various document media such as PDF, html for end-users. But given that more examples and scenarios for a
frozen version of UBLis good and one wouldn't want to release a new sub-version (no pun intended) of UBL.zip
archive which becomes increasingenormous, do you think it's better to separate the specs.zip from the
examples.zip? You might even have example-1.zip, example-2.zip, etc giving a meaningfully
choreographedexchange of documents, such as "Stationery" scenario asexample-1.zip, "Joinery" as example-
2.zip, and othercontributed sources as example-n.zip. Please do consider.The current gigantic download is
going to be a problem to people having low-bandwidth links.

The first 5 columns (B, C, D, E, F) of row 1 are named as:UBL UID 1, UBL Name 2, Default UBL Name 3, BIE
Dictionary Entry Name 4, Object Class Qualifier 5, respectively. I presume the 12345s are typos and are to be
removed together with their preceding spaces to define the 5 column names. Otherwise please advise as to
how and why these column names differ from the rest of 7 Excel sheets (including the Reusable)

Sorry to be nit-picking, but the names of the Excel spreadsheets don't seem to be consistently spaced across
the 7 doc-types. "DespatchAdvice", "OrderCancellation", "OrderResponse", and "ReceiptAdvice" are joint
without space while "Order Response Simple" sheet is named with spaces. Would you like to last one to
"OrderResponseSimple"?

UBL_Library_Op70_ReceiptAdvice.xls Row 10 blank: Under "Default UBL Name" and and "BIE Dictionary Entry
Name" in the above spreadsheet, the cells are blank. Should they be "DeliveryRequirement" and "Receipt
Advice.Delivery Requirement" respectively?

UBL_Library_0p70_OrderCancellation.xsd IssueDate name mismatch wish xls version: The 2nd <xsd:element>
with ref="IssueDateDateTime" appears to mismatch that described in the spreadsheet. Taking the spreadsheet
to be the source version, perhaps this "IssueDateDateTime" should read "IssueDate". This element's
"./xsd:annotation/xsd:documentation/ccts:BBIE@dictionaryEntryName" has value "Order Cancellation. Issue_
Date. Date Time", where the suffix ". Date Time" is not found in the spreadsheet version. Which one is to be
updated? The spreadsheet or the xsd?


                                                    Page 57
                                                0p70 Comments


UBL_Library_0p70_Order.xsd bunch of missing minOccurs/maxOccurs. Again, this assumes the
corresponding spreadsheet version has the (correct) values. These happen within the Order Schema. The list
goes as follows:
<xsd:element ref="cat:ID"> field, minOccurs="1" maxOccurs="1" missing.
<xsd:element ref="cat:IssueDate"> field, minOccurs="1" maxOccurs="1" missing.
<xsd:element ref="AcknowledgementResponseCode"> field, maxOccurs="1" missing.
<xsd:element ref="TransactionCurrencyCode"> field, maxOccurs="1" missing.
<xsd:element ref="PricingCurrencyCode"> field, maxOccurs="1" missing.
<xsd:element ref="EarliestDate"> field, maxOccurs="1" missing.
<xsd:element ref="CancelledByDate"> field, maxOccurs="1" missing. Spreadsheet's field has value "Cancelled
ByDate" with a wrongly spaced separation in "Default UBL Name" column.
<xsd:element ref="ValidityDurationMeasure"> field, maxOccurs="1" missing.
<xsd:element ref="LineItemCountQuantity"> field, maxOccurs="1" missing.
<xsd:element ref="TaxTotalAmount"> field, maxOccurs="1" missing.
<xsd:element ref="LineExtensionTotalAmount"> field, maxOccurs="1" missing.
<xsd:element ref="TotalPackagesCountQuantity"> field, maxOccurs="1" missing.
<xsd:element ref="cat:GrossWeightMeasure"> field, maxOccurs="1" missing.
<xsd:element ref="cat:NetWeightMeasure"> field, maxOccurs="1" missing.
<xsd:element ref="cat:NetNewWeightMeasure"> field, maxOccurs="1" missing.
<xsd:element ref="cat:GrossVolumeMeasure"> field, maxOccurs="1" missing.
<xsd:element ref="cat:NetVolumeMeasure"> field, maxOccurs="1" missing.
<xsd:element ref="cat:BuyerParty"> field, minOccurs="1" maxOccurs="1" missing.
<xsd:element ref="cat:SellerParty"> field, minOccurs="1" maxOccurs="1" missing.
<xsd:element ref="cat:FreightForwarderParty"> field, maxOccurs="1" missing.
<xsd:element ref="cat:SalesConditions"> field, maxOccurs="1" missing.
<xsd:element ref="cat:DeliveryTerms"> field, maxOccurs="1" missing. Spreadsheet's field has value "Delivery
Terms" with a wrongly spaced separation in "Default UBL Name" column.
<xsd:element ref="cat:DestinationCountry"> field, maxOccurs="1" missing.
<xsd:element ref="cat:OrderLine"> field, minOccurs="1" missing. Spreadsheet's field has value "Order Line"
with a wrongly spaced separation in "Default UBL Name" column.

In reviewing the Schemas that were generated I was surprised to see the redefinition of complexTypes for the
various address and party types. For instance:
      <xsd:element name="Address" type="AddressType"/>
      <xsd:complexType name="AddressType" id="UBL000028">
      <xsd:element name="DeliverToAddress" type="DeliverToAddressType"/>
      <xsd:complexType name="DeliverToAddressType" id="UBL000145">
      <xsd:element name="JurisdictionAddress" type="JurisdictionAddressType"/>
      <xsd:complexType name="JurisdictionAddressType" id="UBL000309"> and there are others.
It seems that the only thing that really changes is the description of elements in the different aggregates, but
from what I see the "address" content stays the same. I would have expected to see something like this:
      <xsd:element name="Address" type="AddressType"/>
      <xsd:complexType name="AddressType" id="UBL000028">
      <xsd:element name="DeliverToAddress" type="AddressType" id="UBL000145"/>
      <xsd:element name="JurisdictionAddress" type="AddressType" id="UBL000309"/>
Was the previous sample what was really intended to be generated as the final schema? I see how it helps in
the mapping of the definitions of all the various types of address, but it really complicates the final
implementation when you have (in my sample) 3 different definitions of the same complexType, rather than




                                                     Page 58
                                               0p70 Comments

UBL documents cannot be digitally signed directly.




There is no standard way of reporting errors in a UBL document.




There is no standard way of providing an application level acknowledgement




                                                     Page 59
                                               0p70 Comments

There is no standard way of rendering a UBL document into human readable form.




Instead of current UBL scope (EDI or EDIFACT specific), as we talked andpromised our comments to you, we
at Convergys would like to see the following type of work (under UBL-T or UBL-C Technical Committee) carried
forward. We would be interesting in providing support for such standardization efforts (if approved) - OSS/BSS
Business Language Standards (I would call it - UBL-C for Universal Business Language for Communications
Industry - that would include):
   Object Definition and Interactions for:
        - Events (types, field definitions)
        - Account (attributes - public, private/custom)
        - Subscription (types)
        - RateFactor (types, associations)
        - Customer (types/profiles)
        - Services (types, public/private)
    Interface definitions using WSDL
    Discovery of Objects/Services via UDDI
    Transport mechanism (SOAP over TCP/IP)
Hope this helps in your meetings this week. We will follow-up with you in next 10 days.




                                                   Page 60
                                               0p70 Comments

Regarding UBL, Partner IDs, and Security:
Assume that you have a business message like a purchase order
   <Order>
     <From name="Big Buyer Corp.">
         <OurRef name="John Doe"/>
     </From>
     <To name="MegaCar International"/>
     <Item>10 Medium-sized SUVs</Item>
     <Comment>Make it quick please!</Comment>
   </Order>
Now assume that "Big Buyer Corp." is an advanced organization using digital signatures. How should the
identity as expressed in the document relate to the identity as expressed by the signer's certificate?

Among the complications we find
1. The PKI-identity is presumably "strong" as it is vouched for by a CA, while the identity in the business
document is only "claimed" by the entity itself. ==> The PKI identity is governing?
2. The hierarchical naming system used by PKI (X.500) is completely different to the various naming schemes
used in businesses.
3. Some PKI-folks claim that signatures should be tied to individuals. Does this mean that the signer's
certificate in the sample should identify John Doe of Big Buyer Corp.?
4. The receivers (relying parties) are automated processes supposed to handle similar messages from
numerous business parties.
5. Current e-commerce standards like ebXML and Web Services does
   NOT address this basic question.

My own conclusion is that PKI was created to support e-mail where these questions do not arise. For other
types of messaging, PKI in its current shape does not scale well, or at least creates as many new problems as it

The design principle "Garden of Eden" seems to me a very good choice. Every of the different possible design
principles has advantages ant shortcomings, but - at lest in my view - "Garden Of Eden" provides a means for a
consistent, reliable, and reusable definition of elements. However, in version 0p70 seems to be a fracture:
Example:
BuyerParty - is based on BuyerPartyType (both representing ABIE Buyer)
SellerParty - is based on SellerPartyType (both representing ABIE Seller)
Every of these …PartyTypes has the same structure, defined as local ComplexType. However, object class
term is Party, which seems to require a class Party (in UML) or a named complex type 'PartyType'. This
PartyType them should be used and - if necessary - extended by SellerPartyType and BuyerPartyType. This
PartyType seems to be an aggregate core component (ACC), which should be present in the schema.
In UBL 0p70 there seem to be the following ACC:
- Address (this is defined as ABIE but is sometimes used as ACC (e.g. in -eliverToAddressType) and
sometimes as ABIE (e.g. in PartyType, but there I would wonder, why not PartyAddress analogous PartyName)
- Contact
- Financial Account
- Item Identification
- Party
- Period
This list might be incomplete.
The advantage of using ACC as named CompleyTypes seems to me obvious:
- consistent transformation of CCTS into a schema
- completeness of individual BIEs and their structural congruence does not depend on the developer
(independent whether schema or Excel table is used) but is maintained automatically.
- Future changes and extension will have to be applied once and are inherited automatically by the BIE. As it is
now, any extension to the structure of a party would have to be implemented in various BIEs.




                                                    Page 61
                                                0p70 Comments

Many elements have an ID, which is always mandatory. I assume there is an design principle lying behind that.
For practical application this seems to be a bit strange. Assuming an order transaction issued by a small
company without a high sophisticated ERP system I wonder, how all these IDs have to be generated. I cannot
see how to equip every address or contact with a unique ID in the above mentioned case.
Usage of Quantity.
Quantity is a CCT, but it is used often as BBIE:
OrderLine/Quantity
DeliverySchedule/Quantity
OrderedPackage/Quantity
Wouldn't it be better to distinguish and to name BBIE semantically?
OrderLine/OrderedQuantity
DeliverySchedule/ScheduledQuantity
OrderedPackage/CapacityQuantity oder ContainedQuantity
I realise that there are abbreviation rules for names, but if these rules result in semantically ambiguous names
they shouldn't be applied.




Tag name: TofollowQuantity It‟s the duplicate of tag ToFollowQuantity


Tag name: TofollowReason. It‟s the duplicate of tag ToFollowReason


Tag name: ServicelevelCode. It‟s the duplicate of tag ServiceLevelCode.



We would expect to see document types for Order, Order Cancellation, Order Response, Order Response
Simple all defined in a single "Order Domain" namespace. Unfortunately, that isn't the case in 0p70. That
release assigns each document type to its own separate namespace. Namespace per Domain -- not
per Document.




The "Common Aggregate Types" Namespace (“cat”) is Bloated The "Reusable" or "Common Aggregate
Types" (cat) namespace was designed to contain vocabulary _shared_ between the various domain
namespaces. Unfortunately, in the 0p70 release, the cat namespace contains many vocabulary items that are
_not_ shared between the various domains. In fact it contains the whole vocabulary sans the CCT's and the
document types themselves.




                                                    Page 62
                                                0p70 Comments

Basic questions relating to the “History” of the messages:
We would like to have a proper understanding of the reasoning behind the architecture of the Class Diagram
and the messages. Is it possible to have the business/information needs of the users as well as conclusions
reached by the working group that developed the diagrams? Are there reports or summaries of meetings that
we could follow through the design process?
On which base have these message been constructed? Are they based on business process diagrams? On
concrete examples from an industry sector?
Actual purpose of the messages:
In some instances it is said that the messages have only to be developed for the purpose of creating the library
of business information entities. In other instances, including your [Jon] e-mail, the messages are presented as
core messages for everybody i.e. to be actually used, starting point for more dedicated messages, This is
creating confusion and should be clarified.

Inter-relation of the blocks in the Class Diagrams:
We need to try and understand how the different blocks are related to each other, e.g. the payment data in the
Order are related to „allowance/charges‟ rather than the Order or eventually the Order line? In the Invoice, the
payment data are linked directly to the Invoice. The structure of the address do not take into account the way
most of the European companies are presenting the address Why does the country code have a separate
class, referred by specific meanings of the country (Destination country, Country of Origin, ..)
Differences in naming conventions:
We noted differences between the terms used in the class diagrams and the corresponding terms in the html
files.
Examples: ID >< OrderID, IssueDate><OrderIssueDate.


Business Processes:
In the Order to Invoice process, The „Order change‟ procedure is implemented by canceling the original order
and replacing it with a new order. If we look closely, we find there is no link between the original order and the
new order. This may cause very adverse effects in some industries as the issue of the new order may signify re-
starting the whole manufacturing process anew. We would recommend a single order change request
message with the requested changed values, e.g. changed quantity, changed delivery date…

All the following refers to the UBL_Library_0p70_Reusable.xsd and its corresponding spreadsheet. More
specifically, these are row-by-row comparisons between what is defined in the final rows of the Reusable
schema file (those with type = “cct:XXXXXX”) with what is stored on the Reusable spreadsheet.

The left-hand-side is a direct copy from the final rows of the Reusable schema, while the right-hand-side is a re-
generated schema from the Reusable spreadsheet, using the “Default UBL Name” column for value of attribute
name, and the “Representation Term” for value of attribute type.

Red ink marks those areas that appear to have some problems or with spelling errors.
See http://softml.net/jedi/ubl/comment/UBL_Comment-0p1-20030311.htm for details).

Footnotes:
(1)CatalogueID and CatalogueIssueDate are apparently referred to in the <ReferencedCatalogue> object
class. There are 2 elements within <Referenced Catalogue>, with Default UBL Name as “Identifier” and
“IssueDate” respectively. Should they instead be “CatalogID” and “CatalogIssueDate” respectively? Why are
“Catalogue”s here spelled in British format when other usage such as <FromCatalogIndicator> is spelled in




                                                     Page 63
                                                0p70 Comments

All the following refers to the UBL_Library_0p70_Reusable.xsd and its corresponding spreadsheet. More
specifically, these are row-by-row comparisons between what is defined in the final rows of the Reusable
schema file (those with type = “cct:XXXXXX”) with what is stored on the Reusable spreadsheet.

The left-hand-side is a direct copy from the final rows of the Reusable schema, while the right-hand-side is a re-
generated schema from the Reusable spreadsheet, using the “Default UBL Name” column for value of attribute
name, and the “Representation Term” for value of attribute type.

Red ink marks those areas that appear to have some problems or with spelling errors.
See http://softml.net/jedi/ubl/comment/UBL_Comment-0p1-20030311.htm for details).

Footnotes:

   For
(2)	 comments with “<!-- Referenced Excel field absent in Reusable def -->”, it means the “Default UBL
Name” in the spreadsheet has referenced the right-hand-side name, but it isn‟t found in the schema. This could
be due to a few reasons, such as Excel field misspelled, missing definition in schema, etc.

All the following refers to the UBL_Library_0p70_Reusable.xsd and its corresponding spreadsheet. More
specifically, these are row-by-row comparisons between what is defined in the final rows of the Reusable
schema file (those with type = “cct:XXXXXX”) with what is stored on the Reusable spreadsheet.

The left-hand-side is a direct copy from the final rows of the Reusable schema, while the right-hand-side is a re-
generated schema from the Reusable spreadsheet, using the “Default UBL Name” column for value of attribute
name, and the “Representation Term” for value of attribute type.

Red ink marks those areas that appear to have some problems or with spelling errors.
See http://softml.net/jedi/ubl/comment/UBL_Comment-0p1-20030311.htm for details).

Footnotes:

   For
(3)	 comments with “??????????????”, it means the field is not being referenced in the Excel spreadsheet
when the corresponding field is defined in the schema. Like (2), there could be a few reasons that caused this.



There were inconsistencies in the use of CamelCasing when there is a presence of dash. E.g. "E-mail" or "E-
Mail", "CountrySub-Entity" or "CountrySub-entity".

How static are the UBLmmmnnn id values? Ie. can they change over differing releases as some elements are
added/ removed from the same version of XSDs and from different versions?
What is the policy on generating these values?
<xsd:element ref="DeliveryDate"> is shown as "DeliveryDateDate" in spreadsheet. Maybe spreadsheet is not
right in spelling? Row 13 of DespatchAdvice.xls has empty "Default UBL Name" and "BIE Dictionary Entry
Name". They should be "DeliveryRequirement" and an auto-computed BIE name respectively perhaps. The
following have extra space in spreadsheet's "Default UBL Name" column: "Despatch Line" "Freight
ForwarderParty" "DespatchedTransport Handling Unit" "Delivery Terms"




                                                     Page 64
                                                 0p70 Comments

The header row names have 1, 2, 3, ... 36 suffixed for each column name, except column L which is hidden.
Again, I assume these trailing integers are to be removed together with their preceding spaces in order to be
consistent with other spreadsheets. The "Default UBL Name" column for "Tax PointDate" has an extra space
before "Point". The "Default UBL Name" column for "ReferencedDespatch Advice" has an extra space before
"Advice". The "Default UBL Name" column for "ReferencedReceipt Advice" has an extra space before
"Advice". The "Default UBL Name" column for "Payment Means" has an extra space before "Means". The
"Default UBL Name" column for "Payment Terms" has an extra space before "Terms". The "Default UBL
Name" column for "Allowance Charge" has an extra space before "Charge". The "Default UBL Name" and "BIE
Dictionary Entry Name" columns at Row 19 are blank. The should probably be "ExchangeRate" and an auto-
computed dictionary entry string. The "Default UBL Name" column for "Tax Total" has an extra space before
"Total". The "Default UBL Name" column for "Legal Totals" has an extra space before "Totals". The "Default
For rows 199 & 200 in the spreadsheet, under column "ABIE, BIE or ASBIE", are those spaces between "ASB
IE" extras? The 2 rows are also not reflected in corresponding stylesheet Resuable.xsd.
Spelling error for "dspatch" in definition attribute of: <xsd:element ref="cat:BuyerParty" ...> <xsd:annotation>
<xsd:documentation> <ccts:ASBIE definition="....."/>
In Resuable, the unused attributes such as qualifierTerm_PropertyTerm are left undefined, while the unused
attributes in the 7 document schemas allow empty strings to be defined for unused attributes. Is there specific
meaning attached to an attribute being defined as empty string versus being undefined in the schemas?

The qualifier attribute for "objectClassTerm" is "qualifierTermObjectClassTerm", but the same for
"propertyTerm" is "qualifierTerm_PropertyTerm" with the underscore. In both cases, we also have repeated
use of "Term". Finally, even though "propertyTerm" and "representationTerm" follow those column names
defined in the spreadsheets, the corresponding qualifier terms do not (they are prefix in the schemas and suffix
Near spreadsheet).
in thethe end of file, casing error in "LineitemCountQuantity": <xsd:element name="LineitemCountQuantity"
type="cct:QuantityType"/>

ReceiptAdvice.xsd references <xsd:element ref="cat:ReferencedDespatchAdvice" ...> but the spreadsheet
defines under Default UBL Name records the value as "ReferencedDeliveryAdvice".


There is a lack of definition for the attribute "Representation Term Qualifier" as defined in the spreadsheets. As
this column "qualifies" the representation term and the representation term is defined in the schemas, would
there be some information loss if we convert from spreadsheet to schema? In the case of taking schema as
normative and attempting to convert from schema back to spreadsheet, then how would one deduce the right
value for the column under "Representation Term Qualifier"?
Some "dictionaryEntryName" attribute values are composed of information taken from "Representation Term
Qualifier" (such as rows 3 to 8 of DespatchAdvice.xls) but some are not (such as the rest of the rows in
DespatchAdvice.xls). Why is that the case? Is there any flag or indication as to which formula is used in each
situation?

Need UIDs assigned here to ensure interoperability

Where is it identified that Accounts contact is actually a re-use of Contact? Applies to many other re-uses e.g.
59, 79, 90 etc
Has a property qualifier of „returnable‟. This use of the property qualifier contradicts the comment box for
column heading. We believe the comment is correct and property qualifier should not be used for BBIE‟s.
ALSO APPLIES TO NUMEROUS OTHER LINES e.g 16, 17, 18, 20, 21, 22, 23, 24, 36, 37, 38, 41 etc.
What‟s the difference between Handling Code and Handling Type Code?

What is difference between net and gross if net net is gross net of packaging?

What‟s difference between gross and net volume?




                                                     Page 65
                                                 0p70 Comments

Address is not a ABIE but an ACC it has no business meaning until you give it context (associate with a party or
a role such as billing)
Use of term „multiplier‟ in property qualifier does not match description.

Description is for ASBIE not ABIE.

Description missing for contract type code

Country Details description missing

Destination Country description missing

Destination Party Account Id Code - name is unclear given description.

Default UBL name and Dictionary entry name are incorrect - don‟t match the component parts.

It is not only FIs that have branches, the re-usable aggregate should be just „Branch‟ when linked to a FI the
ASBIE would be „FIBranch‟
HI Temp Measure does not work. It repeats so will not be able to differentiate what the different temps mean

Name incorrect it‟s not HazardousTransit Details it‟s HazardousGoods. Transit Details - there‟s a difference!

Description missing

Shouldn‟t handling instructions be a separate re-usable aggregate that is then associated with ordered
shipment
Should be singular it‟s Tax Amount Details

Wrong description

Wrong description

Name incorrect - it is owner type (as per description) and not owner party type (they are not types of party)


Row 264 Column “UBL Definition” has blank definition.

The color coding legend isn‟t apparent or available in the spreadsheet. Presumably, pink starts the
complexType, followed by white rows of fields within the complexType. What does green color signify? The
deep orange color seems to be for highlighting unresolved or questionable areas. But what about the light
orange at row 126, columns P & Q? What does that color signify?
The UBL UID running numbers are notcontinuous. In DespatchAdvice schema, for example, we have
UBL500001, but the next higher UID is UBL500004, then UBL500006.

Rows 87, 110, 347, 561 and 604 Column “UBL Definition” states “What is this?” Is anyone providing the
answer?
Element:[Extension] Attribute “definition” has value “What is this?”

Element:[TaxLevelCode] Attribute “definition” has value “?”




                                                     Page 66
                                                0p70 Comments

We need Document Instance ID tag to be inserted into all 7 document schemas.




I am not experienced in XML and XML schemas so my questions may be rooted in inexperience. In that case,
the answers to these questions could form part of a FAQ on UBL. I am contemplating using UDL as a basis for
a web service to order charts for aircraft pilots targeted at large resellers. This would be an add-on to an E-
Commerce application that I maintain for that customer base.

1) Why do I have to keep using the <cat:ID> element on everything, even when it is not being used? This is
especially obvious in the supplied example OfficeSupplyOrderInstance.xml . By my count 40 out of 49 times the
element is used, it is empty.
2) My application is nowhere near as comprehensive as this schema. I have no use for most of the elements,
and I don't want to spend my time programming logic to account for them. I was thinking of issuing my own
schema for an order that would be based on the UDL one by restriction. That way, my customer would know
what I my requirements are and would still know that any valid order for me, is also a valid UDL order, though
the converse would not be true. However, because you use global naming I don't think I am allowed to do that.
Sure I can build a restriction on <order:Order> which I call <naco:Order>. I can also restrict <cat:OrderLine>
into <nacocat:OrderLine>, however I think that if I replace <cat:OrderLine> with <nacocat:OrderLine> in
<naco:Order> then <naco:Order> is no longer a valid restriction of <order:Order>. On the other hand, if local
naming was acceptable for <OrderLine> then I could do that.

Normative Source And Production Source Issue

I need to ask team members to recognize that there is a misalignment between what is the normative source
and the production source in 0p70. The team is pronouncing the schemas (.xsd) files to be the normative
source, but explains that the spreadsheets (.xls) generate the schemas. The lists of spelling differences,
extraneous characters, missing elements, missing attributes and many other discrepancies found between the
schemas and the spreadsheets seem to tell a different story. If one takes the spreadsheets and tries to
regenerate the schemas, the regenerated schemas differ in minor, but unsystematic, ways from those
published in the xsd directory.
The effects to external readers are that there could be confusion as to which source is definitive, questions over
why the normative source is generated from non-XML sources, and affects the confidence in the use of
schemas (for e.g. should developers using UBL schemas cater to the ability to read spreadsheets just so that
future UBL releases that are source-rooted on spreadsheet sources can be independently verified?). This is
less than desirable.
Current situation in 0p70:




See http://softml.net/jedi/ubl/comment/UBL_Comment-0p1-20030315.htm for additional details.




                                                     Page 67
                                                0p70 Comments

Packaging And Perception Issue

The presence of spreadsheets in the current 0p70 release, coupled with the publicity that they are the
production source generating the schemas, raises questions about the choice of spreadsheet instead of XML to
be the production source.
As we saw the in archive of comments, there is already an individual voicing such as an issue. That may not be
the only voice as there may be others who are confused by the spreadsheets (and the stress on them
generating the schemas) but who do not know how to ask or if it is right to ask.

The UBL team needed a sufficiently convenient tool to get all the masses of element and attribute definitions in
place; that tool just happened to be spreadsheet, and that‟s perfectly fine. However, these perceptions and
lingering doubts, whether rightly perceived or wrongly conceived, should still be addressed in a more
fundamental way than explaining repeatedly to them to accept the way it is in 0p70.

See http://softml.net/jedi/ubl/comment/UBL_Comment-0p1-20030315.htm for details).
Given the situations described in comments (1) & (2) above, and with inputs from other sources on various
other aspects of 0p70, it is perhaps better to have at least one more 0pNN version to stabilize the
inconsistencies, and to test the new production and release methods. The point is, the next closest version to
1p00 should be as stable and doubt-free as we can get or as confidence can give before 1p00 could be
released. Hopefully time schedule permits this.

See http://softml.net/jedi/ubl/comment/UBL_Comment-0p1-20030315.htm for details).




                                                    Page 68
                                     0p70 Comments




Severity/   Comment     References
Priority    Category



            Editorial




            Editorial


            Editorial



            Editorial




                                        Page 69
           0p70 Comments

CCTS




CCTS




CCT



CCT




CCT




BIE




Modeling




              Page 70
           0p70 Comments

Modeling




Modeling




Modeling




Modeling




Modeling




              Page 71
            0p70 Comments

Modeling




Modeling




Modeling




Modeling




Modeling




Editorial




               Page 72
            0p70 Comments

Editorial


Editorial


BIE




BIE




CCT




Approach




Modeling

Modeling




Modeling


Modeling



Modeling




               Page 73
            0p70 Comments

Modeling




Modeling


Modeling



Modeling




Samples



Packaging




Editorial




Editorial




Editorial




               Page 74
0p70 Comments




   Page 75
0p70 Comments




   Page 76
0p70 Comments




   Page 77
      0p70 Comments




NDR




         Page 78
               0p70 Comments

Modeling



CCT / Naming




Editorial


Editorial


Editorial




                  Page 79
                            0p70 Comments

Modeling    Document
            EEG1-2003-006




Scope       Document EEG1-
            2003-006




Modeing     Document EEG1-
            2003-006




Editorial   Document EEG1-
            2003-006




Modeling    Document EEG1-
            2003-006




Editorial




                               Page 80
            0p70 Comments

Editorial




Edtorial




Editorial


Editorial


Editorial




               Page 81
            0p70 Comments

Editorial




Editorial

Editorial

Question



Editorial




Editorial




Question




Question




               Page 82
0p70 Comments




   Page 83
0p70 Comments




   Page 84
0p70 Comments




   Page 85
                                                   0p70 Comments




Proposed Solutions




Jon (http://lists.oasis-open.org/archives/ubl-lcsc/200301/msg00193.html):
The OASIS eGov technical committee set the example I think we should be following at its first
meeting in Baltimore last month when it decided that it would use only OASIS formats for its papers
and specifications. I think that we should adopt the same policy.
It seems to me that the 0p70 review cycle is the perfect opportunity to get all of our formats over to
openoffice before we have to publish the next big release in May. We have to figure out how to publish
UBL Part 2 as a single document in this span anyway, so we might as well make the changeover at the
same time.

Robert Shmit:I agree with Jon B's comment here and reflects the spirit of my concern. Just use XML.

Same as for comment 1.1.


Same as for comment 1.1.



When putting this together, John and I discussed this issue of the XSD.asn module which is defined in
ITU-T X.694. This module contains many module which is defined in ITU-T X.694. This module
contains many definitions not relevant to UBL, and we were not sure we wanted to produce a modified
reduced version of the XSD.asn module for UBL which did not match the full definition in X.694, so we
left it out of this first review copy. Obviously there is interest in this and I will discuss with John exactly
what from the XSD.asn we will need to include in the package (whether the full module, or the reduced
subset needed by UBL).
Date: Sat, 08 Mar 2003 08:43:11 +0000
From: John Larmouth <j.larmouth@salford.ac.uk>
The relevant module was present in the first version we produced in Boston, so there is not much
work to dust it off and integrate it in. Paul is away on an extended trip at present, and does not have a
lot of time (and seems to be off e-mail a fair bit too, unusually for him!), but I am absolutely certain we
can get a complete and syntax-checked version to you before April 28th. I will try to target a couple of
weeks time. - John L




                                                        Page 86
                                                0p70 Comments

LCSC work with CCTS members (Mark, Sue, primarily) to understand metamodel described in Section
6.1, 6.2, 7.1.




Garret Minakwa: I recommend that they [commonAttributes Attribute Group] be removed from
CoreComponentTypes.xsd and placed in a UBL-specific extension to CoreComponentTypes.xsd.
Gunther Stuhec:There was no decision about the common attributes in UBL yet. Therefore, we
removed this commonAttributes Attribute Group completely.
Garret and Gunther agreed that we're using all Supplementay Components for each Core Component
Type. If a Supplementary Component will be not used in the UBL specific schema, it will be still defined
but it will get the implicit attribute use="prohibited".




Gunther removed all ids, because the ids are not decided yet. This is an issue of UBL or ebXML CCTS.
NDR define structure, LC decide names.
Needs to be done before harmonization meeting in July.




                                                    Page 87
                                               0p70 Comments




Bill: The Change Order was going to be a complete refresh of the Order, with an additional 'change
code'. So it was decided (not by me) to just do a cancellation, and then reissue the Order.




                                                   Page 88
                                              0p70 Comments




Delete the declarations and references to: ServicelevelCode. (Spreadsheet)




                                                  Page 89
                                               0p70 Comments

Delete the declarations and references to: TofollowQuantity. (Spreadsheet)
Check Editor's Note.

Delete the declarations and references to: TofollowReason. (Spreadsheet)




                                                   Page 90
                                               0p70 Comments




Bill: The Change Order was going to be a complete refresh of the Order, with an additional 'change
code'. So it was decided (not by me) to just do a cancellation, and then reissue the Order.


Show ReceiptAdvice (and all other documents) in samples.
Bill is working with Mike on samples which will go on the web site in the FAQ and samples. For
someone new to UBL it would be very useful to see how the span of all the documents are used in the
trading scenario.
Break out samples.




Not sure how those numbers got in there. They shouldn't be in there.




This is an inconsistency. Squeeze out spaces, should be OrderResponse and others mentioned.




Should be "DeliveryRequirement" and "Receipt Advice.Delivery Requirement" respectively?



Problem is that schema is declared normative, but it is genearted from spreadsheets. Should have
some intermediate release to fix all these problems and then from then on xchemas are source and
spreadsheets are produced from schemas. Schemas should be source, not other way around.




                                                   Page 91
                                                0p70 Comments


Fill in missing min/max occurs, but issue has to do more with policy of default values.




Should all map to AddressType or PartyType?
Is this script abnormality or conscious decision?




                                                     Page 92
                                                0p70 Comments

Add an optional XML Dsig element to the root of each document and guidelines on how it should be
used.
Often the authenticity of a UBL document will need to be determined using cryptographic techniques.
One way of doing this is to sign the document together with the envelope in which it is contained as, for
example, ebXML Messaging provides [1]. However, this means that you HAVE to keep the message
around in order to later prove authenticity when the message is being processed. This adds to
complexity and only works if messaging protocols such as ebXML Messaging are being used.
A better alternative is to include an XML DSig digital signature [2] element as an *optional* element at
the root level of every UBL document. I would also recommend that a guideline is provided that
describes how XML digital signatures should be used inside a UBL document in order to improve
interoperability.
[1] ebXML Messaging specifications, http://www.oasis-open.org/committees/ebxml-msg/#documents
[2] W3C XML Digital Signature Specification, http://www.w3.org/TR/xmldsig-core/
QA Team recognized importance of this area. Security was out of scope for 0p70, but will be taken up
at F2F.


Define and add an "Error Response" document as part of the standard set of UBL Documents.
This comments suggests including a standard "error response" document, within UBL. It is
inevitable, that some UBL documents will contain errors that prevent their successful
processing. However there is currently no standard way by which the sender of the original
message can be informed of this fact. The provision of a standard error response document
that could be used to communicate this information would make implementation of
interoperable solutions much easier to realize.


Define and add an "Application Acknowledgement" document as part of the standard set of
UBL Documents.
This comment suggests the inclusion of a standard "application acknowledgement" document,
within UBL. Note that this acknowledgement is generated by the *application* that is actually
processing the UBL document and is independent of any "messaging" level acknowledgement
that might be generated (as ebXML Messaging does). As an example, the nature of the
acknowledgement can vary from:
Document Received - i.e. the document was successfully extracted from the message
envelope
Document Structure OK - i.e. it is a valid structure that conforms to its XML Schema, or
Document Checked OK - i.e. the content of the document is correct. This can include cross
checking of one field against another as well as, for example, checking that identifiers of
products or parties have been validated as correct against internal databases




                                                    Page 93
                                             0p70 Comments

Add optional elements/ attributes to each document that references a style sheet that can be
used to render the UBL document into viewable form. XML is designed to be machine-
readable. Although human beings can read XML, it is not easy and to someone who does not
understand XML, it is very confusing. Also, as UBL moves into its next phase, where
multiple versions of XML documents will exist that depend on the context in which it is
being used, identifying a way of making UBL document instances human-readable will
become more complex. This comment proposes a standard way of solving this problem that
involves:
	
 Adding an optional reference to each UBL document, that identifies an XSLT stylesheet that
can be used to render the UBL document into human readable form.
	refinement would be to permit multiple stylesheet references so that a stylesheet may be
 A
selected depending on the language used by the reader and whether or not the document is to
be printed or viewed/displayed in a browser.
	further refinement would define how to digitally sign the stylesheet(s) referenced, so that
 A
the authenticity of the stylesheet being used could be determined.

Note that use of stylesheet references is entirely optional.




                                                 Page 94
                                               0p70 Comments

The remedy is probably (I had some troubles following the very complex UBL schemas), incompatible
with UBL. A LONG-TERM REMEDY:

To create a foundation for more frictionless PKI-secured e-business, I think that there *long-term*
should be a one-to-one mapping between [basic] business message identities and certificate identities.
As the business community is not going to adopt X.500 naming, as well as having their own naming
problems, this will likely require changes on both sides. A possible scheme using the currently only
globally functioning naming system (DNS/URIs), is that entities are uniquely defined by two elements:

- A naming domain (name space) based on a URI like: "http://www.visa.com/cc"
- A local identifier in that domain like: 4555-5555-2244-8888

Although the example identified a credit-card, the scheme works for just about any kind of object or
entity. An advantage of using HTTP URIs is that you usually can get further information "by clicking on
the link".




                                                    Page 95
                                              0p70 Comments

Yes, it is a design principle. This is something that can be taken up for review.
Find out from Mike and Gunther why this is done this way. If agree, then NDR will update document
and use of the attribute mandatory. Logic behind this needs to be clear for those developing schemas.




See comment 6.2.


See comment 6.3.


See comment 6.1.



The recommendation here is that in the next UBL release we merge those many namespaces into
one, "Order". From lines 650-653 in version 21 of the NDR doc (<http://oasis-
open.org/committees/ubl/ndrsc/release/wd-ublndrsc-ndrdoc-21.do> c): Two higher-level "domain"
namespaces are defined, one for the "ordering" domain and another for the "invoicing" domain. The
Order Domain namespace defines message types and ABIEs specific to the ordering domain.
Similarly, the Invoice Domain namespace defines message types and ABIEs specific to the invoicing
domain.
Identify the vocabulary elements that are shared among two or more domains. Those would go into
the “cat” namespace. For the remainder, each would be "pushed up" into a domain namespace.
draft-burcham-modnamver-08.pdf (version 8 of position paper: Modularity, Namespace,
Versioning from NDRSC) lines 243-245: The import rule presents a namespace as an
indivisible grouping of types. A “piece” of a namespace can never be used without all it’s
pieces. It is therefore important to strive to define namespaces that are minimal and
orthogonal. As it stands, the “cat” namespace is more maximal than minimal.




                                                  Page 96
                                            0p70 Comments

We look forward to meeting you and other UBL experts at UN/CEFACT Forum. If necessary we are
willing to provide more details of our concerns based on a complete review of the messages,
especially through the UN/CEFACT Forum process




Follow CCTS rules




                                                Page 97
                                               0p70 Comments




Ensure consistency in at least minor revisions. Consider impact of any inconsistency in major versions.




                                                   Page 98
                                               0p70 Comments




 All these would be removed if we could just follow consistently the spreadsheet naming style. So:
qualifierTermObjectClassTerm => objectClassQualifier objectClassTerm => objectClass
qualifierTerm_PropertyTerm => propertyQualifier propertyTerm => propertyTerm (OK)
representationTerm => representationTerm (OK)




Unless there is some reason not to do so, then the Representation Term Qualifier should be carried
from the spreadsheet to the schema (using tools).



Need consistency of formulas across the spreadsheet.




Assign UBL UIDs

Identify „of type‟ in column „L‟.

Rename in-line with comment box at top of Property Qualifier column.


Clearer descriptions required from business experts

Clearer descriptions required

Clearer descriptions required




                                                   Page 99
                                                 0p70 Comments

Change type from ABIE to ACC

Remove use of word multiplier in name or add it into description, depending on appropriate business
use. Comment is specific to this row only.
Correct description

Add description

Add description

Add description

Need to clarify this is an account at the „seller‟? Work „seller assigned‟ or similar into name. Or should
this be an ASBIE?
Correct UBL and dictionary names

Create re-usable aggregate called „Branch Details‟. Have a re-use for FI branch. Should also expand
FI - not understood by non English speaking or people from other domains.
Split out and name separate occurrences (as 260) or create a separate aggregate and associate.

Rename to Hazardous Goods. Transit

Add description

Create separate reusable aggregate „Handling Instructions‟

Make tax amounts singular.

Correct description

Correct description

Change name so property term is „owner type‟.


To describe the entity

Explain the color coding.



Compactize the sequence numbers so that they are continuous. Although the UIDs are just for unique
identification purposes, having a continuous ID sequence facilitates debugging and accounting of ID
usage.
To replace the specified cells with answers instead of a question.




                                                     Page 100
                                                  0p70 Comments

Add
<Header> <DocumentID> UUID </DocumentID> </ Header>
to insert as the first item before “ID” of each of 7document schemas. The UUID is to be an on-the-fly-
generated value on creation of a document instance. The wrapping <Header > tag allows future
additional document-instance related information to be added in a grouped manner. Also provides for
expansion of meta-info fields that are likely to be needed by work-flow/ doc-management systems.
Please refer to the discussion thread on ubl-lcsc with subject “Document instance ID”.

This ties in to Generic Header. Need to decide if this is within scope.




If the normative and production sources continue to be different, stricter “production line discipline”
may need to be put in place to modify only the spreadsheets and regenerate all schemas from the
spreadsheets mechanically. But that does not really solve the root of the problem.
I propose to align both the normative source with the production source, so that the status of the
spreadsheets is reduced to just an augmenting “reading aid”, just like the current UML diagrams.
Proposed Production Method in next release:




By doing so, all future modifications, proposed changes and editorial touch-ups will be made directly to
the schema files. Once the changes are updated on the schema files, the spreadsheets can be
mechanically and completely re-generated by tools to provide a more human-readable version and for
the convenience of other interested UBL readers who might not have better schema reading tool than
a browser.
Proposed Next Release Action
  * Reduce the spreadsheets to the status of “reading aid”.
  * Ensure that the spreadsheets are consistent with the schemas.
  *Find or work out tools to generate spreadsheets mechanically and completely without any post-
generation modification.



                                                     Page 101
                                                 0p70 Comments

Assuming comment (1) above and its proposals are adopted, the spreadsheets are no longer of any
central importance. That being the case, I propose that in the next release, the schema files and
related documentation be published in one release archive, related reading aid and supplementary
files in another release archive, and finally, sample scenario and related files in individual archives
(one sample per archive as they are rather large).
In particular, the advantage of having one specific archive storing all the definitive schemas is that it
allows clear and easy references to these definitive schemas. People will only have one thing to read
(the schemas). I understand that this may be a subjective opinion about the manner of archiving and
style of release (one archive of everything as in 0p70 versus separate specific archives for specific
main and supplementary components of UBL), but I think it‟ll contribute to clarity and that indirectly
helps the overall image of UBL.
Proposed Next Release Action
    * Adopt “Proposed Next Release Action” of comment (1).
    * Take out all non-definitive and non-essential files from the present 0p70 and archive them
separately.
    * For the main specification archive, ensure that only the essential schemas, work out a version
Assuming proposals in comments (1) & (2) above are adopted, this proposes todocumentation and
0p80 before 1p00.

Adopt “Proposed Next Release Action” of comment (1) and (2).
Publish next release as 0p80.




                                                     Page 102
                                           0p70 Comments




SC Owner      Solution    Solution   QA Owner        Next QA Action/       Next QA       Next QA
(LC / NDR /   Owner       Due Date                   Milestone             Action/       Action/
...)                                                                       Milestone     Milestone
                                                                           Due Date      Status

LCSC          Jon Bosak   2.May.2003 QA Team         Present to LCSC at F2F 2.May.2003
              Tim
              McGrath




LCSC          Jon Bosak   2.May.2003 QA Team         Present to LCSC at F2F 2.May.2003
              Tim
              McGrath
LCSC          Jon Bosak   2.May.2003 QA Team         Present to LCSC at F2F 2.May.2003
              Tim
              McGrath

LCSC          Paul Thorpe 28.April.200 QA Team       Present to LCSC at F2F 2.May.2003
              John        3
              Larmouth




                                                 Page 103
                              0p70 Comments

LCSC       Mike          Mike/Sue       Discuss in LCSC before 14. Apr. 2003
           Adcock                       F2F.
           Sue Probert




LCSC (w                  QA Team        Present to LCSC at F2F 28.Apr.2003
CM)




LCSC                     QA Team        Present to LCSC at F2F 28.Apr.2003



NDR                      Lisa Seaburg Start discussion on      14. Apr. 2003
                                      NDR list.




NDR/LCSC                 Lisa Seaburg Start discussion on      14. Apr. 2003
                                      NDR list for NDR
                                      completion before F2F


LCSC                     QA Team        Present to LCSC at F2F 28.Apr.2003




LCSC                     Lisa Seaburg Discuss in next LCSC     28. Mar. 2003
                                      call




                                    Page 104
             0p70 Comments

LCSC   Lisa Seaburg Discuss in next LCSC        28. Mar. 2003
                    call




LCSC   QA Team        Bill send Steven's last   28.Apr.2003
                      reply, for the record –
                      1.April.2003




LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?

                 Page 105
             0p70 Comments

LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?
LCSC   Sue Probert,   Take comments on          15.April.2003
       Mike Adcock    business schemas and
                      (with Tim) come up with
                      proposal with how to
                      deal with this in
                      modeling. How does
                      this relate to Modeling
                      discussion paper that
                      Mike is currently
                      working on?

LCSC   QA Team        Present to LCSC at F2F 28.Apr.2003




                 Page 106
            0p70 Comments

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003


LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003


LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003


LCSC   Mike Adcock



LCSC   Mike Adcock




                 Page 107
                  0p70 Comments

LCSC         Mike Adcock




LCSC         Mike Adcock


LCSC         Mike Adcock



LCSC         Mike Adcock




             Bill Meadows Check with Steven
                          Cowe.


LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003



LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003



Tools and    QA Team       Present to LCSC at F2F 28.Apr.2003
Techniques




                       Page 108
                  0p70 Comments


LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC /       Sue Probert / Discuss with NDR      26. Mar. 2003
Tools and    Lisa Seaburg (larger team).
Techniques




                       Page 109
            0p70 Comments

       Lisa Seaburg Send mail to Eve for   25. Mar. 2003
                    initial evaluation




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




                 Page 110
                   0p70 Comments

FPSC          Sue Probert     Correspond with David 28. Mar. 2003
                              regarding creation of
                              new SC, and make sure
                               David's respons is
                              included in the
                              spreadsheet. Also copy
                              email to Ken Holman.




Context       Peter Yim       Notify Eduardo of issue. 25. Mar. 2003
Methodology




                          Page 111
              0p70 Comments

NDR      Lisa Seaburg Send email to Eve for   25. Mar. 2003
                      initial evaluation




NDR/TT   Sue Probert   LCSC discuss, then     26. Mar. 2003
                       hand off to TTSC
                       before F2F.




LCSC     Sue Probert   Address w/r/t ccts     28. Apr. 2003
                       naming design rules.
                       Before F2F (understand
                       documents).




                  Page 112
                   0p70 Comments

LCSC         Marion Royal Investigate to find root   28. Mar. 2003
                          cause and determine
                          appropriate action.

NDR/LCSC     Lisa Seaburg Should LC have been        26. Mar. 2003
                          using quaifiers? If yes,
                          LCSC, if not, NDR.




LCSC         QA Team        Present to LCSC at F2F 28.Apr.2003


LCSC         QA Team        Present to LCSC at F2F 28.Apr.2003


LCSC         QA Team        Present to LCSC at F2F 28.Apr.2003



Tools and    QA Team        Present to LCSC at F2F 28.Apr.2003
Techniques




LCSC         QA Team        Present to LCSC at F2F 28.Apr.2003




                       Page 113
           0p70 Comments

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




                 Page 114
               0p70 Comments

LCSC       QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC       QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC       QA Team       Present to LCSC at F2F 28.Apr.2003


LCSC/NDR   QA Team       Present to LCSC at F2F 28.Apr.2003


           QA Team       Present to LCSC at F2F 28.Apr.2003




                     Page 115
             0p70 Comments

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003



LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   Monica Martin Ask Gunther to           4. Apr. 2003
                     investigate this problem
                     and determine cause
LCSC   Monica Martin Ask Gunther to           4. Apr. 2003
                     investigate this problem
                     and determine cause

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003


LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC   QA Team       Present to LCSC at F2F 28.Apr.2003




                 Page 116
                 0p70 Comments

LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003




LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003



Tools and    QA Team       Present to LCSC at F2F 28.Apr.2003
Techniques

LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003

LCSC         QA Team       Present to LCSC at F2F 28.Apr.2003




                       Page 117
          0p70 Comments

NDR   QA Team       Present to LCSC at F2F 28.Apr.2003




                Page 118
0p70 Comments




  Page 119
                                        0p70 Comments




QA Team   QA Team Comments                    UBL
Status                                        Artifacts
                                              Effected


Ready




Ready


Ready



Ready     Suggestion: possibly add to FAQ.




                                             Page 120
                                         0p70 Comments

In progress




Ready




Ready



In progress.




In progress    Lisa add to NDR agenda.




Ready




In progress




                                           Page 121
                                          0p70 Comments

In progress




Ready         Recommendation: LCSC to review
              the process of Change Order and
              make a disposition.




In progress




In progress




In progress




In progress




                                                Page 122
              0p70 Comments

In progress




In progress




In progress




In progress




In progress




Ready




                Page 123
                                                 0p70 Comments

Ready


Ready


Ready         Refer to item 3.6.




Ready




Ready




Ready




Ready

Ready         QA Recommendation: smaller team
              to look at this for short-term strategy
              and possibly clearly state scope of
              UBL o this area.



Ready         QA Recommendation: smaller team
              to look at this for short-term strategy.

In progress   QA Recommendation:
              SC should look at the
              generalisation/specialization issues

In progress




                                                     Page 124
                              0p70 Comments

In progress




In progress   Refer to 5.8.


In progress   Refer to 5.8.



In progress   Refer to 5.8.




In progress   Also see 4.1.



Ready



Ready




Ready




Ready




Ready



Ready




                                Page 125
                                        0p70 Comments


Ready




In progress   Lisa add to NDR agenda.




                                          Page 126
               0p70 Comments

In progress.




Ready




Ready




                 Page 127
                                             0p70 Comments

In progress.




In progress    Liaise through CM (and also
               ontology) perscpective.




                                               Page 128
                                               0p70 Comments

In progress.   Link to David Burdett comments to
               ensure consistent reponse.




In progress.   Out of scope for current work, but
               would be addressed when UBL
               goes through UN/CEFACT
               harmonization?




In progress.   Lisa add to NDR agenda.




                                                    Page 129
                                                0p70 Comments

In progress



In progress.




Ready          Suggestion: Mike look at this before
               F2F

Ready          Suggestion: Mike look at this before
               F2F

Ready          Suggestion: Mike look at this before
               F2F


Ready          This may be how the script reads
               the spreadsheet. There is no official
               rule for how this should be dealt with
               in the tools. This is a joint
               discussion between the two teams
               for an official position and possible
               modification of script
Ready          This may be how the script reads
               the spreadsheet. There is no official
               rule for how this should be dealt with
               in the tools. This is a joint
               discussion between the two teams
               for an official position and possible
               modification of script




                                                    Page 130
        0p70 Comments

Ready




Ready




Ready




Ready




Ready




Ready




          Page 131
        0p70 Comments

Ready




Ready




Ready


Ready


Ready




          Page 132
                                              0p70 Comments

Ready




Ready

Ready

Ready         Inconsistency in spreadsheret that
              should be addressed in the F2F.
              Similar to the min/max occurs
              comment.
Ready




In progress


In progress



Ready




Ready




Ready

Ready

Ready         Should BBIEs use Propety
              Qualifiers?

Ready

Ready

Ready




                                                   Page 133
                                         0p70 Comments

Ready        Look at modeling issues
             surrounding address.
Ready

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned

Unassigned


Ready

Ready        QA Recommendation: add table of
             contents


Ready


Ready

Ready

Ready




                                               Page 134
                                            0p70 Comments

Ready        Lisa will put on agenda for NDR.




Unassigned




Unassigned




Unassigned




                                                Page 135
             0p70 Comments

Unassigned




Unassigned




               Page 136
0p70 Comments




  Page 137
0p70 Comments




  Page 138
0p70 Comments




  Page 139
0p70 Comments




  Page 140
0p70 Comments




  Page 141
0p70 Comments




  Page 142
0p70 Comments




  Page 143
0p70 Comments




  Page 144
0p70 Comments




  Page 145
0p70 Comments




  Page 146
0p70 Comments




  Page 147
0p70 Comments




  Page 148
0p70 Comments




  Page 149
0p70 Comments




  Page 150
0p70 Comments




  Page 151
0p70 Comments




  Page 152
0p70 Comments




  Page 153
0p70 Comments




  Page 154
0p70 Comments




  Page 155
0p70 Comments




  Page 156
0p70 Comments




  Page 157
0p70 Comments




  Page 158
0p70 Comments




  Page 159
0p70 Comments




  Page 160
0p70 Comments




  Page 161
0p70 Comments




  Page 162
0p70 Comments




  Page 163
0p70 Comments




  Page 164
0p70 Comments




  Page 165
0p70 Comments




  Page 166
0p70 Comments




  Page 167
0p70 Comments




  Page 168
0p70 Comments




  Page 169
0p70 Comments




  Page 170
0p70 Comments




  Page 171
0p70 Comments




  Page 172
0p70 Comments




  Page 173
0p70 Comments




  Page 174
0p70 Comments




  Page 175
0p70 Comments




  Page 176
0p70 Comments




  Page 177
0p70 Comments




  Page 178
0p70 Comments




  Page 179
0p70 Comments




  Page 180
0p70 Comments




  Page 181
0p70 Comments




  Page 182
0p70 Comments




  Page 183
0p70 Comments




  Page 184
0p70 Comments




  Page 185
0p70 Comments




  Page 186
0p70 Comments




  Page 187
0p70 Comments




  Page 188
0p70 Comments




  Page 189
0p70 Comments




  Page 190
0p70 Comments




  Page 191
0p70 Comments




  Page 192
0p70 Comments




  Page 193
0p70 Comments




  Page 194
0p70 Comments




  Page 195
0p70 Comments




  Page 196
0p70 Comments




  Page 197
0p70 Comments




  Page 198
0p70 Comments




  Page 199
0p70 Comments




  Page 200
0p70 Comments




  Page 201
0p70 Comments




  Page 202
0p70 Comments




  Page 203
0p70 Comments




  Page 204
0p70 Comments




  Page 205
0p70 Comments




  Page 206
0p70 Comments




  Page 207
0p70 Comments




  Page 208
0p70 Comments




  Page 209
0p70 Comments




  Page 210
0p70 Comments




  Page 211
0p70 Comments




  Page 212
0p70 Comments




  Page 213
0p70 Comments




  Page 214
0p70 Comments




  Page 215
0p70 Comments




  Page 216
0p70 Comments




  Page 217
0p70 Comments




  Page 218
0p70 Comments




  Page 219
0p70 Comments




  Page 220
0p70 Comments




  Page 221
0p70 Comments




  Page 222
0p70 Comments




  Page 223
0p70 Comments




  Page 224
0p70 Comments




  Page 225
0p70 Comments




  Page 226
0p70 Comments




  Page 227
0p70 Comments




  Page 228
0p70 Comments




  Page 229
0p70 Comments




  Page 230
0p70 Comments




  Page 231
0p70 Comments




  Page 232
0p70 Comments




  Page 233
0p70 Comments




  Page 234
0p70 Comments




  Page 235
0p70 Comments




  Page 236
0p70 Comments




  Page 237
0p70 Comments




  Page 238
0p70 Comments




  Page 239
0p70 Comments




  Page 240
0p70 Comments




  Page 241
0p70 Comments




  Page 242
0p70 Comments




  Page 243
0p70 Comments




  Page 244
0p70 Comments




  Page 245
0p70 Comments




  Page 246
0p70 Comments




  Page 247
0p70 Comments




  Page 248
0p70 Comments




  Page 249
0p70 Comments




  Page 250
0p70 Comments




  Page 251
0p70 Comments




  Page 252
0p70 Comments




  Page 253
0p70 Comments




  Page 254
0p70 Comments




  Page 255
0p70 Comments




  Page 256
0p70 Comments




  Page 257
0p70 Comments




  Page 258
0p70 Comments




  Page 259
0p70 Comments




  Page 260
0p70 Comments




  Page 261
0p70 Comments




  Page 262
0p70 Comments




  Page 263
0p70 Comments




  Page 264
0p70 Comments




  Page 265
0p70 Comments




  Page 266
0p70 Comments




  Page 267
0p70 Comments




  Page 268
0p70 Comments




  Page 269
0p70 Comments




  Page 270
0p70 Comments




  Page 271
0p70 Comments




  Page 272
0p70 Comments




  Page 273
0p70 Comments




  Page 274
0p70 Comments




  Page 275
0p70 Comments




  Page 276
0p70 Comments




  Page 277
0p70 Comments




  Page 278
0p70 Comments




  Page 279
0p70 Comments




  Page 280
0p70 Comments




  Page 281
0p70 Comments




  Page 282
0p70 Comments




  Page 283
0p70 Comments




  Page 284
0p70 Comments




  Page 285
0p70 Comments




  Page 286
0p70 Comments




  Page 287
0p70 Comments




  Page 288
0p70 Comments




  Page 289
0p70 Comments




  Page 290
0p70 Comments




  Page 291
0p70 Comments




  Page 292
0p70 Comments




  Page 293
0p70 Comments




  Page 294
0p70 Comments




  Page 295
0p70 Comments




  Page 296
0p70 Comments




  Page 297
0p70 Comments




  Page 298
0p70 Comments




  Page 299
0p70 Comments




  Page 300
0p70 Comments




  Page 301
0p70 Comments




  Page 302
0p70 Comments




  Page 303
0p70 Comments




  Page 304
0p70 Comments




  Page 305
0p70 Comments




  Page 306
0p70 Comments




  Page 307
0p70 Comments




  Page 308
0p70 Comments




  Page 309
0p70 Comments




  Page 310
0p70 Comments




  Page 311
0p70 Comments




  Page 312
0p70 Comments




  Page 313
0p70 Comments




  Page 314
0p70 Comments




  Page 315
0p70 Comments




  Page 316
0p70 Comments




  Page 317
0p70 Comments




  Page 318
0p70 Comments




  Page 319
0p70 Comments




  Page 320
0p70 Comments




  Page 321
0p70 Comments




  Page 322
0p70 Comments




  Page 323
0p70 Comments




  Page 324
0p70 Comments




  Page 325
0p70 Comments




  Page 326
0p70 Comments




  Page 327
0p70 Comments




  Page 328
0p70 Comments




  Page 329
0p70 Comments




  Page 330
0p70 Comments




  Page 331
0p70 Comments




  Page 332
0p70 Comments




  Page 333
0p70 Comments




  Page 334
0p70 Comments




  Page 335
0p70 Comments




  Page 336
0p70 Comments




  Page 337
0p70 Comments




  Page 338
0p70 Comments




  Page 339
0p70 Comments




  Page 340
0p70 Comments




  Page 341
0p70 Comments




  Page 342
0p70 Comments




  Page 343
0p70 Comments




  Page 344
0p70 Comments




  Page 345
0p70 Comments




  Page 346
0p70 Comments




  Page 347
0p70 Comments




  Page 348
0p70 Comments




  Page 349
0p70 Comments




  Page 350
0p70 Comments




  Page 351
0p70 Comments




  Page 352
0p70 Comments




  Page 353
0p70 Comments




  Page 354
0p70 Comments




  Page 355
0p70 Comments




  Page 356
0p70 Comments




  Page 357
0p70 Comments




  Page 358
0p70 Comments




  Page 359
0p70 Comments




  Page 360
0p70 Comments




  Page 361
0p70 Comments




  Page 362
0p70 Comments




  Page 363
0p70 Comments




  Page 364
0p70 Comments




  Page 365
0p70 Comments




  Page 366
0p70 Comments




  Page 367
0p70 Comments




  Page 368
0p70 Comments




  Page 369
0p70 Comments




  Page 370
0p70 Comments




  Page 371
0p70 Comments




  Page 372
0p70 Comments




  Page 373
0p70 Comments




  Page 374
0p70 Comments




  Page 375
0p70 Comments




  Page 376
0p70 Comments




  Page 377
0p70 Comments




  Page 378
0p70 Comments




  Page 379
0p70 Comments




  Page 380
0p70 Comments




  Page 381
0p70 Comments




  Page 382
0p70 Comments




  Page 383
0p70 Comments




  Page 384
0p70 Comments




  Page 385
0p70 Comments




  Page 386
0p70 Comments




  Page 387
0p70 Comments




  Page 388
0p70 Comments




  Page 389
0p70 Comments




  Page 390
0p70 Comments




  Page 391
0p70 Comments




  Page 392
0p70 Comments




  Page 393
0p70 Comments




  Page 394
0p70 Comments




  Page 395
0p70 Comments




  Page 396
0p70 Comments




  Page 397
0p70 Comments




  Page 398
0p70 Comments




  Page 399
0p70 Comments




  Page 400
0p70 Comments




  Page 401
0p70 Comments




  Page 402
0p70 Comments




  Page 403
0p70 Comments




  Page 404
0p70 Comments




  Page 405
0p70 Comments




  Page 406
0p70 Comments




  Page 407
0p70 Comments




  Page 408
0p70 Comments




  Page 409
0p70 Comments




  Page 410
0p70 Comments




  Page 411
0p70 Comments




  Page 412
0p70 Comments




  Page 413
0p70 Comments




  Page 414
0p70 Comments




  Page 415
0p70 Comments




  Page 416
0p70 Comments




  Page 417
0p70 Comments




  Page 418
0p70 Comments




  Page 419
0p70 Comments




  Page 420
0p70 Comments




  Page 421
0p70 Comments




  Page 422
0p70 Comments




  Page 423
0p70 Comments




  Page 424
0p70 Comments




  Page 425
0p70 Comments




  Page 426
0p70 Comments




  Page 427
0p70 Comments




  Page 428
0p70 Comments




  Page 429
0p70 Comments




  Page 430
0p70 Comments




  Page 431
0p70 Comments




  Page 432
0p70 Comments




  Page 433
0p70 Comments




  Page 434
0p70 Comments




  Page 435
0p70 Comments




  Page 436
0p70 Comments




  Page 437
0p70 Comments




  Page 438
0p70 Comments




  Page 439
0p70 Comments




  Page 440
0p70 Comments




  Page 441
0p70 Comments




  Page 442
0p70 Comments




  Page 443
0p70 Comments




  Page 444
0p70 Comments




  Page 445
0p70 Comments




  Page 446
0p70 Comments




  Page 447
0p70 Comments




  Page 448
0p70 Comments




  Page 449
0p70 Comments




  Page 450
0p70 Comments




  Page 451
0p70 Comments




  Page 452
0p70 Comments




  Page 453
0p70 Comments




  Page 454
0p70 Comments




  Page 455
0p70 Comments




  Page 456
0p70 Comments




  Page 457
0p70 Comments




  Page 458
0p70 Comments




  Page 459
0p70 Comments




  Page 460
0p70 Comments




  Page 461
0p70 Comments




  Page 462
0p70 Comments




  Page 463
0p70 Comments




  Page 464
0p70 Comments




  Page 465
0p70 Comments




  Page 466
0p70 Comments




  Page 467
0p70 Comments




  Page 468
0p70 Comments




  Page 469
0p70 Comments




  Page 470
0p70 Comments




  Page 471
0p70 Comments




  Page 472
0p70 Comments




  Page 473
0p70 Comments




  Page 474
0p70 Comments




  Page 475
0p70 Comments




  Page 476
0p70 Comments




  Page 477
0p70 Comments




  Page 478
0p70 Comments




  Page 479
0p70 Comments




  Page 480
0p70 Comments




  Page 481
0p70 Comments




  Page 482
0p70 Comments




  Page 483
0p70 Comments




  Page 484
0p70 Comments




  Page 485
0p70 Comments




  Page 486
0p70 Comments




  Page 487
0p70 Comments




  Page 488
0p70 Comments




  Page 489
0p70 Comments




  Page 490
0p70 Comments




  Page 491
0p70 Comments




  Page 492
0p70 Comments




  Page 493
0p70 Comments




  Page 494
0p70 Comments




  Page 495
0p70 Comments




  Page 496
0p70 Comments




  Page 497
0p70 Comments




  Page 498
0p70 Comments




  Page 499
0p70 Comments




  Page 500
0p70 Comments




  Page 501
0p70 Comments




  Page 502
0p70 Comments




  Page 503
0p70 Comments




  Page 504
0p70 Comments




  Page 505
0p70 Comments




  Page 506
0p70 Comments




  Page 507
0p70 Comments




  Page 508
0p70 Comments




  Page 509
0p70 Comments




  Page 510
0p70 Comments




  Page 511
0p70 Comments




  Page 512
0p70 Comments




  Page 513
0p70 Comments




  Page 514
0p70 Comments




  Page 515
0p70 Comments




  Page 516
0p70 Comments




  Page 517
0p70 Comments




  Page 518
0p70 Comments




  Page 519
0p70 Comments




  Page 520
0p70 Comments




  Page 521
0p70 Comments




  Page 522
0p70 Comments




  Page 523
0p70 Comments




  Page 524
0p70 Comments




  Page 525
0p70 Comments




  Page 526
0p70 Comments




  Page 527
0p70 Comments




  Page 528
0p70 Comments




  Page 529
0p70 Comments




  Page 530
0p70 Comments




  Page 531
0p70 Comments




  Page 532
0p70 Comments




  Page 533
0p70 Comments




  Page 534
0p70 Comments




  Page 535
0p70 Comments




  Page 536
0p70 Comments




  Page 537
0p70 Comments




  Page 538
0p70 Comments




  Page 539
0p70 Comments




  Page 540
0p70 Comments




  Page 541
0p70 Comments




  Page 542
0p70 Comments




  Page 543
0p70 Comments




  Page 544
0p70 Comments




  Page 545
0p70 Comments




  Page 546
0p70 Comments




  Page 547
0p70 Comments




  Page 548
0p70 Comments




  Page 549
0p70 Comments




  Page 550
0p70 Comments




  Page 551
0p70 Comments




  Page 552
0p70 Comments




  Page 553
0p70 Comments




  Page 554
0p70 Comments




  Page 555
0p70 Comments




  Page 556
0p70 Comments




  Page 557
0p70 Comments




  Page 558
0p70 Comments




  Page 559
0p70 Comments




  Page 560
0p70 Comments




  Page 561
0p70 Comments




  Page 562
0p70 Comments




  Page 563
0p70 Comments




  Page 564
0p70 Comments




  Page 565
0p70 Comments




  Page 566
0p70 Comments




  Page 567
0p70 Comments




  Page 568
0p70 Comments




  Page 569
0p70 Comments




  Page 570
0p70 Comments




  Page 571
0p70 Comments




  Page 572
0p70 Comments




  Page 573
0p70 Comments




  Page 574
0p70 Comments




  Page 575
0p70 Comments




  Page 576
0p70 Comments




  Page 577
0p70 Comments




  Page 578
0p70 Comments




  Page 579
0p70 Comments




  Page 580
0p70 Comments




  Page 581
0p70 Comments




  Page 582
0p70 Comments




  Page 583
0p70 Comments




  Page 584
0p70 Comments




  Page 585
0p70 Comments




  Page 586
0p70 Comments




  Page 587
0p70 Comments




  Page 588
0p70 Comments




  Page 589
0p70 Comments




  Page 590
0p70 Comments




  Page 591
0p70 Comments




  Page 592
0p70 Comments




  Page 593
0p70 Comments




  Page 594
0p70 Comments




  Page 595
0p70 Comments




  Page 596
0p70 Comments




  Page 597
0p70 Comments




  Page 598
0p70 Comments




  Page 599
0p70 Comments




  Page 600
0p70 Comments




  Page 601
0p70 Comments




  Page 602
0p70 Comments




  Page 603
0p70 Comments




  Page 604
0p70 Comments




  Page 605
0p70 Comments




  Page 606
0p70 Comments




  Page 607
0p70 Comments




  Page 608
0p70 Comments




  Page 609
0p70 Comments




  Page 610
0p70 Comments




  Page 611
0p70 Comments




  Page 612
0p70 Comments




  Page 613
0p70 Comments




  Page 614
0p70 Comments




  Page 615
0p70 Comments




  Page 616
0p70 Comments




  Page 617
0p70 Comments




  Page 618
0p70 Comments




  Page 619
0p70 Comments




  Page 620
0p70 Comments




  Page 621
0p70 Comments




  Page 622
0p70 Comments




  Page 623
0p70 Comments




  Page 624
0p70 Comments




  Page 625
0p70 Comments




  Page 626
0p70 Comments




  Page 627
0p70 Comments




  Page 628
0p70 Comments




  Page 629
0p70 Comments




  Page 630
0p70 Comments




  Page 631
0p70 Comments




  Page 632
0p70 Comments




  Page 633
0p70 Comments




  Page 634
0p70 Comments




  Page 635
0p70 Comments




  Page 636
0p70 Comments




  Page 637
0p70 Comments




  Page 638
0p70 Comments




  Page 639
0p70 Comments




  Page 640
0p70 Comments




  Page 641
0p70 Comments




  Page 642
0p70 Comments




  Page 643
0p70 Comments




  Page 644
0p70 Comments




  Page 645
0p70 Comments




  Page 646
0p70 Comments




  Page 647
0p70 Comments




  Page 648
0p70 Comments




  Page 649
0p70 Comments




  Page 650
0p70 Comments




  Page 651
0p70 Comments




  Page 652
0p70 Comments




  Page 653
0p70 Comments




  Page 654
0p70 Comments




  Page 655
0p70 Comments




  Page 656
0p70 Comments




  Page 657
0p70 Comments




  Page 658
0p70 Comments




  Page 659
0p70 Comments




  Page 660
0p70 Comments




  Page 661
0p70 Comments




  Page 662
0p70 Comments




  Page 663
0p70 Comments




  Page 664
0p70 Comments




  Page 665
0p70 Comments




  Page 666
0p70 Comments




  Page 667
0p70 Comments




  Page 668
0p70 Comments




  Page 669
0p70 Comments




  Page 670
0p70 Comments




  Page 671
0p70 Comments




  Page 672
0p70 Comments




  Page 673
0p70 Comments




  Page 674
0p70 Comments




  Page 675
0p70 Comments




  Page 676
0p70 Comments




  Page 677
0p70 Comments




  Page 678
0p70 Comments




  Page 679
0p70 Comments




  Page 680
0p70 Comments




  Page 681
0p70 Comments




  Page 682
0p70 Comments




  Page 683
0p70 Comments




  Page 684
0p70 Comments




  Page 685
0p70 Comments




  Page 686
0p70 Comments




  Page 687
0p70 Comments




  Page 688
0p70 Comments




  Page 689
0p70 Comments




  Page 690
0p70 Comments




  Page 691
0p70 Comments




  Page 692
0p70 Comments




  Page 693
0p70 Comments




  Page 694
0p70 Comments




  Page 695
0p70 Comments




  Page 696
0p70 Comments




  Page 697
0p70 Comments




  Page 698
0p70 Comments




  Page 699
0p70 Comments




  Page 700
0p70 Comments




  Page 701
0p70 Comments




  Page 702
0p70 Comments




  Page 703
0p70 Comments




  Page 704
0p70 Comments




  Page 705
0p70 Comments




  Page 706
0p70 Comments




  Page 707
0p70 Comments




  Page 708
0p70 Comments




  Page 709
0p70 Comments




  Page 710
0p70 Comments




  Page 711
0p70 Comments




  Page 712
0p70 Comments




  Page 713
0p70 Comments




  Page 714
                                 Legend

Comment Categories:

Application
Approach
Alignment with other Standards
BIE
CCT
CCTS
Context
Editorial
Modeling
NDR
Packaging
Question
Samples
Other - explain




                                 Page 715

				
DOCUMENT INFO
Description: Free Invoice Template Openoffice document sample