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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[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