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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: [ubl-dev] Details on the Methodology


Tom - 
 
Thank you for your responses - my feedback is inline.
 
Cheers,
-Marcel
 

	-----Mensaje original----- 
	De: Tom Gaven [mailto:Tom.Gaven@exostar.com] 
	Enviado el: Lun 05/01/2004 09:00 a.m. 
	Para: 'Sall, Ken'; Tim McGrath; Tom Gaven 
	CC: ubl-dev@lists.oasis-open.org 
	Asunto: RE: [ubl-dev] Details on the Methodology
	
	
	 
	Ken,
	  I would guess the reason choice and all are forbidden is due to the process used.
	  1. It is painful to represent choice (or all) in Excel spreadsheets.
	 
	MJ> Should this really be a valid-enough reason to not have the use of xs:choice??  Choice is a valid business constraint - one in which several on this list and on xml-dev discuss/use.
	 
	 
	  2. It is painful to model choice (or all) in UML diagrams.
	  
	MJ> I do not know the validity of your statement but I hope that, while painful, it is still representable as W3C XSD can provide for xs:choice content model.    
	 
	 
	 
	3. If you allow choice or all, then do you also allow groups?  (a|b|(c,d,e)|f)  
	 
	MJ> Groups are a healthy means of 'grouping' information - i will download the UBL guidance on this to see if it is allowed but I hope that it is...
	 
	 
	 
	Actually,  it isn't that it's painful to model 'choice' or 'all', it's just painful to model 'more than one' of the 3 possibilities (sequence, choice or all)... and I guess 'sequence' was the lucky winner.
	 
	MJ> Within xs:choice you can have xs:sequence so order can be maintained.  
	 
	 



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