OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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]