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] | [List Home]


Subject: RE: [ubl-ndrsc] NDR Review - Section 7.7


I have yet to see a use case for the inclusion of choice.  In the cases where I have seen arguments for the use of choice, the data is really more properly part of either a code list or identification scheme.  


Mark 



> -----Original Message-----
> From: Eve L. Maler [mailto:Eve.Maler@Sun.COM]
> Sent: Thursday, January 08, 2004 1:39 PM
> To: UBL-NDRSC (E-mail)
> Subject: Re: [ubl-ndrsc] NDR Review - Section 7.7
> 
> 
> Hi folks-- I bet you thought I had fallen off the edge of the earth, 
> huh?  I hope you're all well, and I wish you a happy 2004.
> 
> I wasn't going to comment on this issue, but Mike's message has 
> emboldened me.  As he points out, it poses no particular 
> problems that a 
> maxOccurs greater than 1 doesn't already have, so at the least, the 
> rationale shouldn't be as stated below.
> 
> But beyond that, I think it's a little weird to actually 
> forbid choice 
> groups.  It feels a little like "All that is not mandatory is 
> forbidden".  It's certainly going to be more rare in business 
> documents 
> than in prose documents; perhaps a need for it will pop up in 
> catalogs, 
> which are a hybrid?...  I believe the main reason UBL doesn't 
> have *any* 
> choice groups to date is that its chosen methodology and spreadsheet 
> encoding have no way to accommodate it.  But I can certainly imagine 
> ways for them to do so, if the need arose.
> 
> 	Eve
> 
> Grimley Michael J NPRI wrote:
> 
> > Greetings,
> > 
> > I know we are not currently going to reconsider decisions 
> already made; however, we do have to change the explanatory 
> text around the xsd:choice rule (Section 7.7 - GXS9). It 
> currently reads:
> > 
> > ==================================================
> > The xsd:choice compositor allows for any element declared 
> inside it to occur in the
> > instance document, but only one. As with the xsd:all 
> compositor, this feature is
> > inconsistent with business transaction exchanges and is not 
> allowed in UBL.
> > ==================================================
> > 
> > I don't think this is true. As I had mentioned on 
> yesterday's call, because an xsd:choice element can be 
> contained within an xsd:sequence, it leads to no more 
> uncertainty/variability in an instance than a "minOccurs='0'" 
> does; therefore, I don't believe it is "inconsistent with 
> business transaction exchanges".
> > 
> > Comments?
> > 
> > Thank You,
> > Mike Grimley
> 
> -- 
> Eve Maler                                        +1 781 442 3190
> Sun Microsystems                            cell +1 781 354 9441
> Web Products, Technologies, and Standards    eve.maler @ sun.com
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members
/leave_workgroup.php.



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