[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Revised PRD3 documentation/packaging issues
Hello UBL TC, Following is the list of possible documentation issues that came out of our review session in this week's Pacific call. It's the same as the list I sent out Monday: http://lists.oasis-open.org/archives/ubl/201106/msg00017.html But now the issues have been organized into categories (beginning with the ones that are no longer issues) and assigned to owners. Text in parentheses summarizes the discussion and disposition of each item in the Pacific call. Jon ======================================================================== Already done ======================================================================== Remove NDR annex from 2.1 documentation (Done) Missing document-level signature ASBIE: UBL-CallForTenders-2.1 UBL-CatalogueRequest-2.1 UBL-CertificateOfOrigin-2.1 UBL-ContractAwardNotice-2.1 UBL-ContractNotice-2.1 UBL-PriorInformationNotice-2.1 (All taken care of) ACTION for PRD3: GKH to fix RNC converter so that the signature extension will validate. (Done) Start date for RFQs http://lists.oasis-open.org/archives/ubl-dev/201104/msg00000.html http://lists.oasis-open.org/archives/ubl-dev/201104/msg00001.html http://lists.oasis-open.org/archives/ubl-dev/201104/msg00002.html http://lists.oasis-open.org/archives/ubl-dev/201104/msg00003.html From TC minutes of 4/18: TM: The issue is whether we want to expand RFQ to look like RFP; the difference is in the formality of the process. An RFQ usually comes after an RFP and is more specific; an RFQ does not usually lead into tendering, whereas an RFP does -- but this is different in different countries. (This was discussed in Stockholm. It was decided that RFQ and RFP are different documents and don't need to look the same, so leave as is) Most of the process diagrams are lacking labels for source and destination; should they be supplied? Note that in several cases this means distinguishing between two versions of a figure that would otherwise be identical; see sections 2.13.3.4 through 2.13.3.8. (The process descriptions are modular; we don't want to specify source and destination) ======================================================================== Action items for PSC ======================================================================== Section 2.8 needs to explain billing methods as a matrix, with Primary Doctype and Discrepancy Doctype as the two column headings. Section 2.8.1. should describe invoice calculation model per BII (For example, how do you end up with the total value? We should use the BII approach as a normative business rule.) Section 2.8.4. needs updating to reflect new status messages (The process is now more complex and involves other docs, already in PRD2) Section 2.9. terminology needs updating in text and diagram (Per eFreight) Section A.6. Taxation Rules should be moved to section 2. (Another example of a calculation rule) Section 2.1.4 [was incorrectly cited as 2.14 in the last version of this list] needs to explain price break in terms of item/location/quantity Addition of backordering functionality (probably by adding "backordered" to the code list for line status). (This came from a member of the community via GKH) In 2.15, the first paragraph doesn't mention air transport; is this intentional? (Emphasis on road isn't right either. This section should be rewritten) ======================================================================== Action items for TSC ======================================================================== Section 2.14.4: "Transport Service Buyer and a Transport Service Provider" -- these role names will probably change, requiring updates throughout 2.15 and probably elsewhere (ACTION: TSC to tell JB what should be changed in this case so that he can do the replacements in the DocBook file. The remaining items can be provided as revised texts) Section 2.15 need additions for transport rules. (Audun will explain) In section 2.15.5, the name "Transport Progress Status" needs further discussion. (We need to be very clear about the differences between the different kinds of transport status documents) The language in 2.16 needs to reflect a federated distribution of status -- not just the Freight Forwarder. (Rework) The entry for Transportation Status in 2.18 needs to reflect the federated distribution of status. (Rework) The entry for Certificate of Origin in 2.18 needs to amplify the difference between the UBL COO document type and an actual COO. The current description does not explain this. (It actually *is* the COO, but the COO contains many certificates; it's a document that contains other documents, and the collective set is called "Certificate of Origin." We should explain that the document is structured as a container. ACTION: Write another paragraph) The third paragraph in 2.19 mentions "Qualifying Party," but no such entry appears on the following table; also, there is no mention of the party whose role is Transportation Network Manager or Transport Regulator. (Note that these names are changing) ======================================================================== Action items for TM ======================================================================== Section 2.2: the text needs to match the overview diagram; e.g., replenishment, catalogue and quotations (The structure and titles of subsequent sections don't match Fig. 1. The diagram needs correcting anyway, then 2.1 needs to reflect the diagram, then the titles of the sections that follow need to reflect both. ACTION: TM to revise the diagram, then the editors to revisit the text.) Programmatic correction of the ASBIE definitions. (Discussed in Stockholm; thought nice, but not necessary, and also not enough -- just a start, would still have lots of edge cases to deal with and language to add. ACTION: TM to investigate further. We may decide to defer a wholesale revision of definitions to 2.2; the impact on translation is to be considered. But it is good to look into it now as a Q/A exercise and then decide when to take it to the next level) ======================================================================== Action items for JB ======================================================================== Section 2.1 should be shortened and focus on common structures such as the document ABIE template structures. Section 2.8.1. "an Invoice defines the financial consequences of a business transaction". (Correct the text) Section 2.10. include ' An invoice depends on one or more utility statements$(B ((BAdd to the text) Section 2.11. should be titled 'Payment Notification$(B n(Bot 'Payment$(B ((BCorrect the text) Section 2.11.1 Statement of Account is just called Statement (Correct both diagram and text; EA model is on the web site) Action: Ken - section 1.2. Normative References -- check the latest genericode version (In progress; see gkh 6/20/2011; HTML in order to make the same as with CVA) XAdES description (from Andrea 6/15/2011): I'd like to add that both our our profiles, when using XAdES, can be compliant with the Commission Decision 2011/130/UE that will be in effect starting Aug 1st. All European public administration has to support it and an open source code for verification of documents signed in compliance to this commission decision will be made available from the EU Commission. So I think it's worth to add this in our profile to introducing it in the first sentence of clause 6.3 as follows: "A compliant implementation of XAdES guarantees wide acceptance in implementing legal regulations, such as EC Directive [1999/93/EC] and the Commission Decision [2011/130/UE]," And then add the following informative reference: "[2011/130/UE] Commission Decision 2011/130/UE of the European Commission of 25 February 2011 on establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:01:EN:HTML]." Neither of which substantively changes the specification (if I understand it correctly). (We agree; make the change) Possible reorganization of the hub document (from TM 5/23): Page 76 Table 1. - how hard would it be to link the document names to their schemas? we can then remove section 3.1. now we duplicate (and potential get out of synch.) Generally can we move the Context/Process descriptions to separate documents? This means readers get to the thing they most want to see (the document types and schema links) quicker. We could publish CPFR, VMI, Procurement, Intermodal Freight, etc as separate documents. (We want a single point of entry to the schemas; we have a top-down approach, but then we send users in multiple directions.... Things appear in multiple places.... Should be: here are the processes, link to schemas, link to models.... Rather than 3 lists of 50 items, one list with links. ACTION: JB to consider the implications of this and be ready to respond; final action will probably be a work item for the September meeting in Kars) ======================================================================== Other documentation or packaging issues ======================================================================== Prune the DocBook directory structure (ACTION: JB and GKH, probably in Kars) Add UML diagrams for individual models (Audun appears to have found a tool that will produce acceptable UML diagrams from our schemas. ACTION: Audun to investigate further) Final disposition of the transport contract issue (PRD2 was a stopgap) (We think that we can in fact use a Contract ABIE common to transport and procurement, as implemented in PRD2; we're waiting to hear back from stakeholders in the PRD2 review cycle. ACTION: JB to highlight this in the list of things we're asking the public to consider in reviewing PRD2, as with the signature extension. The question is, "Can we use a common Contract ABIE for a range of business processes, for example both transport and procurement?") ======================================================================== For resolution elsewhere ======================================================================== Action: Arianna - add 'symbology$(B f(Bor barcodes (etc.) to Item Identification. Action: Anyone with domain knowledge should review the tables in 2.18 Document Types and 2.19 Party Roles to ensure that these align and are complete. Requirement from Spain for withholding tax on invoices. (Needs further discussion/review; we think that it's OK the way it is, but we need formal resolution) New document types for CatalogueTemplate and PurchaseConditions. (A PSC issue. The need for these is still under discussion, so we may not actually have them in 2.1) ======================================================================== NDR issues (from GKH 5/22): ======================================================================== a. recorded NDR rule GTD2 states xsd:anyType MUST NOT be used, yet we use it for extensions; I thought we had covered this off earlier with text like "except for the extension mechanism, ...." as I see for GXS1 ... I don't know if this is a problem in NDR a problem transcribing the NDR to this document b. I see that NDR GXS1 has an unresolved link and out-of-context text c. I see all NDR DOCx rules, and GXS4, NMS4, NMS5 and possibly others not listed here, have out-of-context text d. NDR ELD13 and ELD14 makes references to UBLSubsetID (which hasn't existed in any of UBL 2) and the pair of rules are not consistent with the four BBIEs that must follow the extensions element (in order): UBLVersionID, UBLCustomizationID, UBLProfileID and UBLProfileExecutionID. e. NDR GXS11 - xsd:union no longer applicable, especially for code lists now that code lists are not part of normative UBL f. NDR GXS14 - we are, in fact, using xsd:processContents="lax" based on Ken Vaughn's valuable contribution g. NDR GXS13 is out of order, but I'm not sure it applies as descriptive rather than its prescriptive nature ... we don't extend complex types, and our complex types for BBIEs have simple contents that extend our UDT simple types ... I think we need to remove this h. NDR NMC1 sounds just wrong; based on my understanding of "fully qualified path", it is impossible for NMC1 to be enforced because of ABIE reuse through ASBIE referencing. j. NDR SSM18 seems nonsensical - it happens we have one (QDT) but it isn't that we "must" have one ... this probably original was "must not" which is no longer true (These will all be forwarded to the NDR Team)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]