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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] use of 'ID' in documents


There has been some agreement in the past
that it is best to minimize the number of
elements that a mandatory. 'ID' is, I guess, one
we'd expect to be the minimal mandatory
element in a document or ABIE but making
it optional instead has a serious benefit. For
example it might be that GUID would in some
situations be the preferred way to identify a
document whereas in others implementations
it would be ID, perhaps for business reasons.
 
In my view it would be best to have as many
(or even all) elements optional and use some
way other than XSD (such as implementation
guides, as with the SBS or secondary schemas,
as with codelists) to add the business rules
which would be context specific. The primary
schemas should be as 'ur-like' as possible to
allow greater specialization downstream. They
can be tightened downstream but * not *
loosened.
 
All the best
 
Steve
 
 
 
----- Original Message -----
Sent: Sunday, August 14, 2005 2:38 PM
Subject: AW: [ubl] use of 'ID' in documents

both simple choice and a choice of sequences is not covered by the UML oriented CCTS with its graphic view, but indeed, it is a srong business need. It would be good to have rules here both for models and schemas. There are comments, I believe, for the CCTS 2.x project.
Michael Dill
-----Ursprüngliche Nachricht-----
Von: Anne Hendry [mailto:Anne.Hendry@Sun.COM]
Gesendet: Freitag, 12. August 2005 18:12
An: Tim McGrath
Cc: Betty Harvey; ubl@lists.oasis-open.org
Betreff: Re: [ubl] use of 'ID' in documents

Mike has pointed out that in Washington the rule for choice was changed to from 'must not' to 'should not'.

The only reason I raised the question is that what we have now allows a document to go out without a required id.  I suspected this was due to the choice issue, so now that this restriction has been slackened a bit, would you like to restructure this?

-A

Tim McGrath wrote:
but i think you will find xsd:choice is not allowed by the UBL NDRs

Betty Harvey wrote:
I am not sure how you would handle this in the spreadsheets but W3C
schema is capable of modeling this situation:

<xsd:sequence>
 <xsd:choice minOccurs="1">
	<xsd:element ref="BuyersID"/>
	<xsd:element ref="SellersID"/>
 </xsd:choice>
<xsd:element ref="CopyIndicatory"/>
. . .
</xsd:sequence>

If the choice is optional, i.e., no BuyersID or SellersID, then the
"minOccurs" attribute would be set to 0.

Betty

On Thu, 11 Aug 2005, Tim McGrath wrote:

  
this comes from trying to implement a rule that goes along the lines of...

"all documents must have an ID.  However with some documents (eg Order) 
it may be either the BuyersID and/or the SellersID"

unfortunately we dont have schema (or spreadsheet) syntax for "either 
are optional but one must be used" - which is actually a common rule in 
the real world.  What we have don is the best we can.

Anne Hendry wrote:

    
We notice that some documents contain an 'ID' element.  The 'ID' 
elements seem to be mandatory.  The documents that don't have 'ID' 
seem to have 'BuyersID' and 'SellersID', but those are optional.

Is this an intended modeling aspect that assumes in the documents that 
don't have 'ID' the users would implement either a BuyersID or 
SellersID, even though they are both optional?  Do we want to 
duplicate this model for new documents?  When do you determine you 
want a mandatory ID vs. two optional Buyers|Sellers IDs?

Thanks,
Anne


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in 
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

      
    

  

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476


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