Uploaded image for project: 'OASIS Universal Business Language (UBL) TC'
  1. OASIS Universal Business Language (UBL) TC
  2. UBL-56

Extension content will not validate when foreign element is elided

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: Artefacts
    • Labels:
      None

      Description

      Section 3.5.2 in the specification states that foreign content (that is, namespace-based content unrecognized by an application) in an extension may end up being elided as a result of processing. This elaborates on the rule in IND5 that states the ExtensionContent element is the only element in the document that is allowed to be empty.

      I just discovered today that in the UBL 2.1 schemas ExtensionContent was not allowed to be empty, so that once you elided foreign content the result document would not validate. That bug was carried over into UBL 2.2 all the way up to the latest draft.

      We haven't received any feedback on this from any implementer. We can address this discrepancy in one of a couple of ways:

      • require the instance always to carry all extensions so that in processing no information gets lost (in case that extension information might end up having some meaning downstream in the process, or at some time in the future)
      • change the schema to make the content optional (which may hide a content creation problem where an extension was meant to be present but schema validation doesn't raise any red flags)

      I can see benefits in both ways going forward. But once we make it optional in a final release, for backwards compatibility we can never make it mandatory again, so making a schema change is an important decision.

      We can hold off on schema (conformance) changes and simply remove the documentation that states foreign extension content can be elided and still be considered conforming. I'm leaning a bit in this direction, as I like the idea of not throwing anything out in case it is important in the future.

      But something has to change in csd01wd13 before we vote on it as csd01 ... either the schema or the documentation ... and even if it is the schema, we have public reviews to consider changing it back again to being mandatory since it is mandatory in UBL 2.1.

      What do other members think we should do on this topic?

        Attachments

          Activity

            People

            • Assignee:
              gkholman Ken Holman
              Reporter:
              gkholman Ken Holman
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: