I think we need to be careful if adding extra validation artefacts on UBL. My personal opinion is that they could add some confusion and we are entering a path that could be potentially difficult to handle.
In my opinion, adding this type of artefacts deserves a thourough and deeper discussion in the TC.
Best regards
Oriol
El 9 jul 2020, a les 0:32, G. Ken Holman <gkholman@CraneSoftwrights.com> va escriure:Indeed the sample values were bogus arbitrary strings to populate elements in the sample and were not meaningful. And I agree having more than one defeats the intent of the definition, so we can justify the exception in the tests. I will change the example instance.
In summary, below is the list of "..n" "Text. Type" BBIEs. Nothing other than XPath jumps out at me as not being natural language ... though I had to look up a couple of them:
http://docs.oasis-open.org/ubl/csprd02-UBL-2.3/mod/summary/reports/All-UBL-2.3-Documents.html
If Kees thinks what I've done is acceptable and cannot be improved on, then I will incorporate this into the master branch and update the documentation accordingly. Some in our user base would find this fragment handy to add to their own Schematron scripts. I'll put the fragments into the CVA subdirectory since the fragment is being incorporated into that which is generated from the CVA file.
. . . . . . Ken
cbc:AcceptedVariantsDescription
cbc:AdditionalConditions
cbc:AdditionalInformation
cbc:AllowanceChargeReason
cbc:Article
cbc:AwardingCriterionDescription
cbc:BackorderReason
cbc:BriefDescription
cbc:CalculationExpression
cbc:CancellationNote
cbc:CandidateStatement
cbc:CargoAndBallastTankConditionDescription
cbc:CarrierServiceInstructions
cbc:CertificationLevelDescription
cbc:ChangeConditions
cbc:Conditions
cbc:ConditionsDescription
cbc:Content
cbc:CriterionDescription
cbc:CustomsClearanceServiceInstructions
cbc:DamageRemarks
cbc:DeliveryInstructions
cbc:DemurrageInstructions
cbc:Description
cbc:DocumentDescription
cbc:DocumentStatusReasonDescription
cbc:ElectronicDeviceDescription
cbc:EstimatedTimingFurtherPublication
cbc:ExclusionReason
cbc:ExemptionReason
cbc:ExportReason
cbc:_expression_
cbc:Extension
cbc:FeeDescription
cbc:ForwarderServiceInstructions
cbc:Frequency
cbc:FundingProgram
cbc:GroupingLots
cbc:HandlingInstructions
cbc:HaulageInstructions
cbc:Information
cbc:InstructionNote
cbc:Instructions
cbc:JurisdictionLevel
cbc:Justification
cbc:JustificationDescription
cbc:Keyword
cbc:LimitationDescription
cbc:ListValue
cbc:Location
cbc:LossRisk
cbc:LowTendersDescription
cbc:MeterReadingComments
cbc:MinimumImprovementBid
cbc:ModificationReasonDescription
cbc:MonetaryScope
cbc:NegotiationDescription
cbc:Note
cbc:OptionsDescription
cbc:OtherInstruction
cbc:OutstandingReason
cbc:PackingMaterial
cbc:PaymentDescription
cbc:PaymentNote
cbc:PersonalSituation
cbc:PlannedInspectionsDescription
cbc:PlannedOperationsDescription
cbc:PlannedWorksDescription
cbc:PriceChangeReason
cbc:PriceRevisionFormulaDescription
cbc:PrizeDescription
cbc:ProcessDescription
cbc:ProcessReason
cbc:Purpose
cbc:RegistrationNationality
cbc:RegulatoryDomain
cbc:RejectReason
cbc:RejectionNote
cbc:Remarks
cbc:ReplenishmentOwnerDescription
cbc:Resolution
cbc:Response
cbc:RoleDescription
cbc:ServiceType
cbc:ShipRequirementsDescription
cbc:ShippingMarks
cbc:ShipsRequirements
cbc:SpecialInstructions
cbc:SpecialServiceInstructions
cbc:SpecialTerms
cbc:SpecialTransportRequirements
cbc:StatusReason
cbc:SummaryDescription
cbc:TariffDescription
cbc:TaxExemptionReason
cbc:TechnicalCommitteeDescription
cbc:Text
cbc:Title
cbc:TradingRestrictions
cbc:TransportServiceProviderRemarks
cbc:TransportServiceProviderSpecialTerms
cbc:TransportUserRemarks
cbc:TransportUserSpecialTerms
cbc:TransportationServiceDescription
cbc:ValueQualifier
cbc:WarrantyInformation
cbc:Weight
cbc:WeightScoringMethodologyNote
cbc:WeightingConsiderationDescription
cbc:WorkPhase
cbc:XPath
At 2020-07-08 21:17 +0000, Kenneth Bengtsson wrote:Well done, Ken!
I recall that we had lengthy discussions about it last year when we introduced the ReferencedDocumentInternalAddress. Our conclusion at the time was that the cardinality of the XPath should have been 0..1, and that IND7 and IND8 would, in practice, never be broken because multiple XPath elements within a single DocumentReference would by nature be ambiguous and would therefore violate the definition of the XPath element ("An unambiguous location..").
So it is curious that you have found a sample with two XPath elements. Does this sample use "dummy" values just to demonstrate the XML structure or does it contain meaningful values? If it is just a dummy sample then I think we should stick with our current conclusion and simply change the sample to contain only one XPath. However, if it contains meaningful data from which we can derive a real use case for multiple XPaths then yes, we need to review the NDRs.
/Kenneth
?On 7/8/20, 10:33 PM, "ubl@lists.oasis-open.org on behalf of G. Ken Holman" <ubl@lists.oasis-open.org on behalf of gkholman@CraneSoftwrights.com> wrote:
Fellow UBL TC members,
To address the challenge from Kees (not a formal ticket) regarding
writing Schematron for the additional document constraints:
https://docs.oasis-open.org/ubl/csprd02-UBL-2.3/UBL-2.3.html#S-NATURAL-LANGUAGE-TEXT-ELEMENTS
>Natural language text elements such as Note and Description appear
>throughout the UBL document model.
>...
>UBL enforces this restriction with the following two rules:
>
>[IND7] Where two or more sibling "Text. Type" elements of the same
>name exist in a document, no two can have the same "languageID"
>attribute value.
>
>[IND8] Where two or more sibling "Text. Type" elements of the same
>name exist in a document, no two can omit the "languageID" attribute.
I've written this stylesheet to synthesize what I understand the
requirement to be:
https://github.com/oasis-tcs/ubl-2.3-artefacts/blob/feature/Schematron-document-constraints/UBL-DocumentConstraints-2.3.pattern.xsl
And everything worked ... it even found two sample test files in our
"xml/" directory that violated the rules, so that's good.
But one of the tests also revealed a problem in that not all "Text.
Type" elements are for natural language text, specifically (at least):
>Document Reference. XPath. Text
>http://docs.oasis-open.org/ubl/csprd02-UBL-2.3/mod/summary/reports/All-UBL-2.3-Documents.html#Table-DocumentReference.XPath.Text
And the sample had two XPath address elements, and neither had a
languageID attribute ... a clear violation of the wording of the rule
as stated currently.
But there are no other CCTS data types we can use for just a
generalized string of text:
http://docs.oasis-open.org/ubl/csprd02-UBL-2.3/mod/summary/reports/All-UBL-2.3-Documents.html#UDT
Currently, I'm mechanically distilling all BBIEs of type "Text. Type"
... but because of (at least) cbc:XPath, we need another strategy.
This Schematron is not normative, just a suggestion. We could
document the problem and leave it (not any groups I know use this BBIE).
Or we could enumerate all of the BBIE Property Term Primary Nouns for
things like Note, Description, Instructions, etc. and perhaps miss some.
Or we could enumerate all of the exceptions and perhaps miss some.
At the least, the wording of the rules need to change a bit.
Does anyone have any suggestions regarding how we proceed?
Thanks for your thoughts!
. . . . . . Ken
--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|