Questions and issues w.r.t. BT-738 RequestedPublicationDate

[rkottmann]

Hi,

you have the following rule/assert on RequestedPublicationDate (BT-738)

<assert id="BR-BT-00738-0053" role="ERROR" diagnostics="BT-738-notice" 
     test="( (boolean(
               for $T in (current-date()) 
                 return ($T + xs:dayTimeDuration(cbc:RequestedPublicationDate/xs:date(text()) - cbc:IssueDate/xs:date(text())) &lt; $T + xs:dayTimeDuration('P60D')))) 

              and (boolean(
                    for $T in (current-date()) 
                      return ($T + xs:dayTimeDuration(cbc:RequestedPublicationDate/xs:date(text()) - cbc:IssueDate/xs:date(text())) >= $T + xs:dayTimeDuration('P2D')))))
          or not(cbc:RequestedPublicationDate)">rule|text|BR-BT-00738-0053</assert>

With the following error message

Notice Preferred Publication Date (BT-738-notice) shall be between 2 and 60 days after the Notice Dispatch Date (BT-05-notice)

We have several issues with this:

1. Semantically

   1. What is the business requirement or business rule leading to 2 days after Notice Dispatch Date (BT-05-notice)?

      1. Current understanding from different sources is that if no Preferred Publication Date exists it will be treated as "Publish as soon as possible"
      2. Does a period of 0-2 days mean the same?

   2. What is the business requirement or business rule requiring 60 days? Why do you change this over time?

   3. Germany decided to make The BT-738 Notice Publication Date Preferred mandatory in order to be explicit about differences between BT-05 and BT-738. And we decided to treat a value equal to Notice Dispatch Date

      as "Publish as soon as possible".

   4. We did not expect to have compatibility issues on the semantic level with TED, because the decision was made on analysis of SDK < 1.5.

2. Technically
   1. Why do you use a for loop although the calculation is based on single atomic values?
   2. Why do you use current-day in your calculations? Should it relate to the current day of receiving a notice?
      1. If yes, then it is a bug to use current-date as offset to both sites of the equation
      2. If no, then it is redundant code which can be simplified
      3. Tests show that your current assertion does not throw an error if both dates are within the 2-60 days period but years in the past

Here is how Germany will most probably validate at national level:

    <rule context="$ROOT-NODE/cbc:RequestedPublicationDate">

      <let name="DISPATCH-DATE-NODE" value="../cbc:IssueDate" />

      <assert test="$DISPATCH-DATE-NODE castable as xs:date" id="SR-BT-738-2">[SR-BT-738-2] ../cbc:IssueDate=<value-of select="../cbc:IssueDate"/> is not a valid calendar date.</assert>

      <assert id="SR-BT-738-1" test=" xs:date(.) ge xs:date($DISPATCH-DATE-NODE)" role="error">[SR-DE-26] Calendar date of <name />=<value-of select="." /> must be greater or equals that of cbc:IssueDate=<value-of select="$DISPATCH-DATE-NODE" /></assert>

    <!-- This rule is replacement of BR-BT-00738-0053 to keep compatibility with TED -->
    <assert id="SR-BT-738-P60D" test="xs:date(.) - xs:date($DISPATCH-DATE-NODE) le xs:dayTimeDuration('P60D')">[SR-BT-738-P60D](<name/>) must not be more than 60 days after IssueDate due to TED requirements. <value-of select="concat('Current IssueDate=',xs:date($DISPATCH-DATE-NODE),' and RequestedPublicationDate=', xs:date(.), ' have a difference of ' , days-from-duration( xs:date(.) - xs:date($DISPATCH-DATE-NODE)), ' days.')"/></assert>

<!-- this should only be tested during sending and reception but not for e.g. archived notices, hence an own schematron phase -->
<assert id="current-date-test" test="xs:date($DISPATCH-DATE-NODE) le current-date() and current-date() le xs:date(.)">too old</assert>

    </rule>

[YvesJo]

Hi,
For these business related questions, please contact directly the helpdesk: [email protected]