OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: [ubl-lcsc] Question on element occurrence


We have set a rule in NDR that the nil attribute will not be used. This means no empty elements. The logic behind the decision to not use nil is that in a transaction based environment such as UBL we do not want elements to be excluded or have no content unless we specifically allow it.  This also means that we do not allow the Choice and All Compositors.  When a data element is optional, we use the occurrence indicator minOccurs=0 and simply do not convey the element. We could if we chose have an empty element using minOccurs=0 if declared as a string type but I don't see any value in this.   We have not really made a decision on if we should allow for empty elements for string types. I have a couple of questions:

	1) Is our approach acceptable to the LCSC group?
	2) Does anyone see a use case for conveying empty elements in UBL instance documents?
	2) What about conditionally mandatory elements - elements that may be optional or mandatory depending on  if another element has a certain value or is present.  Is there some combination of compositors and occurrence indicators that will support conducting such a test in the processor, or is this an application level edit that we simply can not address in the schema?



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

Powered by eList eXpress LLC