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: [OASIS Issue Tracker] (UBL-56) Extension content will not validate when foreign element is elided

Ken Holman created UBL-56:

             Summary: Extension content will not validate when foreign element is elided
                 Key: UBL-56
                 URL: https://issues.oasis-open.org/browse/UBL-56
             Project: OASIS Universal Business Language (UBL) TC
          Issue Type: Bug
          Components: Artefacts
            Reporter: Ken Holman
            Assignee: Ken Holman

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?

This message was sent by Atlassian JIRA

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