[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Problem revealed regarding document constraints [IND7] and [IND8]
I am not expecting any production environment to use the committee second-pass validation constructs ... they will have their own.
But it does show a useful task and that task was useful in fixing four of the sample XML instances.
. . . . . . Ken At 2020-07-09 10:23 +0000, Kenneth Bengtsson wrote:
Hi OriolI imagine that these validation artefacts would be provided as tools for guidance and to assist implementors with creating their own validation artefacts? So similar to the XML examples./Kenneth From: "oriol@b2brouter.net" <oriol@b2brouter.net> Date: Thursday, July 9, 2020 at 11:36 AM To: Ken Holman <gkholman@CraneSoftwrights.com>Cc: Kenneth Bengtsson <kbengtsson@efact.pe>, Universal Business Language <ubl@lists.oasis-open.org> Subject: Re: [ubl] Problem revealed regarding document constraints [IND7] and [IND8]Hi allI 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 OriolEl 9 jul 2020, a les 0:32, G. Ken Holman <<mailto:gkholman@CraneSoftwrights.com>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>http://docs.oasis-open.org/ubl/csprd02-UBL-2.3/mod/summary/reports/All-UBL-2.3-Documents.htmlIf 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.TextAnd 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]