[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] Question on element occurrence
CRAWFORD, Mark wrote: >Hi, > >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? > i think we had assumed what you propose anyway. > 2) Does anyone see a use case for conveying empty elements in UBL instance documents? > whilst there is a difference in the information conveyed by using a nill element and not conveying it at all- i don't think this is common practice in document exchanges. if a value is unknown it is generally expressed explicitly as such. > 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? > > These things are actually common in specific context implementations. we discussed this last year and concluded that there are many sophisticated business rules that cannot be expressed in Schema (and maybe shouldn't be). I think Schematron was mentioned as a possible option. We then did some analysis of the types of rules (including the one mentioned above) and concluded that a relatively simple language could be developed to formally specifiy these type of rules. I suggest we pick this up as we get into context rules. >Thoughts? > >Mark > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > > > -- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC