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: PRD3 issues for discussion in Stockholm


Hello UBL TC meeting in Stockholm,

Here, as promised in today's plenary, is a list of miscellaneous PRD3
issues that I've collected from various discussions over the past
several months.  Some of these no doubt duplicate issues that you are
already tracking.  The NDR issues are really a list for the NDR Team;
they are included here for tracking purposes, but you should feel free
to discuss them if you have input for the NDR Team.

Jon

========================================================================

PRD3 ISSUES RELATING TO CONTENT

1. 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

2. Requirement from Spain for withholding tax on invoices.

3. Programmatic correction of the ASBIE definitions.

4. Addition of backordering functionality (probably by adding
    "backordered" to the code list for line status).

5. 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.

6. New document types for CatalogueTemplate and PurchaseConditions.

========================================================================

PRD3 ISSUES RELATING TO DOCUMENTATION

1. Specific questions for Stockholm:

    a. In 2.15, the first paragraph doesn't mention air; is this
       intentional?

    b. 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.)

    c. In section 2.15.5, the name "Transport Progress Status" needs
       further discussion.

    d. The language in 2.16 needs to reflect a federated distribution
       of status (not just the Freight Forwarder).

    e. The entry for Transportation Status in 2.18 needs to reflect the
       federated distribution of status.

    f. 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.

    g. 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.

2. 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.

       [Recommend that we deal with these issues in Kars - JB]

3. 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

       [Recommend that we turn this list over to the NDR team - JB]


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]