Re: [ebxml-bp] Proposal for minOccurs and maxOccurs attributes toAttachment

[YANO Keisuke (矢野啓介 ) <yano@jp.fujitsu.com>]

Monica,

In that schema, Attachment in DocumentEnvelope is optional.  That's
reasonable.  But that doesn't seem to fulfil JEITA's requirement.

JEITA's need is that a defined Attachment can be omitted in execution
time, not to omit Attachment element in a DocumentEnvelope definition.

For example, let's see the following DocumentEnvelope instance.

  <DocumentEnvelope name="SpecExchange" nameID="DE-SpecExchange"
      businessDocumentIDREF="BD-SpecExchange">
      <Attachment name="SpecificationDiagram" nameID="Att-SpecDiagram"
          businessDocumentIDREF="BD-SpecExchange"
          mimeType="application/pdf">
          <Specification location="???"/> <!-- what to specify for PDF? -->
      </Attachment>
  </DocumentEnvelope>

This DocumentEnvelope references the BusinessDocument whose name is 
'SpecExchange' and have one PDF Attachment named 'SpecificationDiagram'.

In some cases, this PDF Attachment is used to convey information that
cannot be expressed by 'SpecExchange' XML BusinessDocument.  On the
other hand, in the cases that the XML BusinessDocument conveys all
needed information, a PDF diagram is not needed.  That is, the defined
PDF Attachment must not be sent.

The schema you showed doesn't seem to allow users to omit the defined
Attachments in execution time.

That's the reason why I propose min/maxOccurs attributes.  If that 
Attachment above is defined such as

      <Attachment name="SpecificationDiagram" nameID="Att-SpecDiagram"
          businessDocumentIDREF="BD-SpecExchange"
          mimeType="application/pdf"
          minOccurs="0" maxOccurs="1"> <!-- *** this line *** -->
          <Specification location="???"/>
      </Attachment>,

an end user can omit the PDF Attachement if not needed.  Of course,
the user can also attach a PDF diagram as needed.

Another good point about min/maxOccurs attributes is the alignment
with ebXML CPPA.  In the CPPA packaging constructs, the Constituent
element has minOccurs and maxOccurs attributes to specify the range of
the values that the item may occur.  The alignment with CPPA is
important because BPSS's BusinessDocument and Attachement elements
affect CPPA's Constituent elements.

For example, the Constituent element corresponding to the Attachment
element above may be following:

  <tp:Constituent tp:idref="AttachmentPart" tp:minOccurs="0" tp:maxOccurs="1"/>

Thanks,

Yano Keisuke


From: "Monica J. Martin" <Monica.Martin@sun.com>
Subject: Re: [ebxml-bp] Proposal for minOccurs and maxOccurs attributes to Attachment
Date: Thu, 14 Oct 2004 13:13:26 -0700

> YANO Keisuke (????) wrote:
> 
> >ebBP TC members,
> >
> >I would like to propose to add the minOccurs and maxOccurs attributes
> >to the Attachment element of BPSS.  An example is following:
> >
> >    <Attachment name="SpecificationAttachment" 
> >        businessDocument="BD:SpecAttachment" businessDocumentIDRef="att"
> >        mimeType="application/pdf"
> >        minOccurs="0" maxOccurs="5"/>  <!-- here -->
> >
> >These attributes are similar to the same name attributes of the
> >Constituent element of ebXML CPPA.  The XML schema fragment for these
> >attributes in the Attachment element definition may be following.
> >
> >    <xsd:attribute name="minOccurs" type="xsd:nonNegativeInteger"/>
> >    <xsd:attribute name="maxOccurs" type="xsd:nonNegativeInteger"/>
> >
> >This proposal is based on the requirement of the ECALGA business
> >process specifications developed by JEITA [1].  They need to specify
> >that an attachment is optional (i.e., minOccurs="0" and
> >maxOccurs="1").  Also, it is likely that they will want to specify
> >that the number of attachments is arbitrary in the future.
> >
> >  
> >
> mm1: Yano-san,
> In preparing to discuss this for Monday's TC call, 18 Oct, I'd like to 
> discuss further. Here is the current draft schema that at first glance 
> appears to meet your needs (see *** below in schema snippet):
> 
>         <xsd:complexType name="DocumentEnvelopeType">
>         <xsd:sequence>
>         <xsd:element ref="Documentation" minOccurs="0"
>         maxOccurs="unbounded"/>
>         **** <xsd:element ref="Attachment" minOccurs="0"
>         maxOccurs="unbounded"/>
>         </xsd:sequence>
>         <xsd:attributeGroup ref="name"/>
>         <xsd:attribute name="businessDocumentIDREF" type="xsd:IDREF"
>         use="required"/>
>         <xsd:attribute name="isPositiveResponse" type="xsd:boolean"/>
>         <xsd:attributeGroup ref="documentSecurity"/>
>         </xsd:complexType>
>         <xsd:element name="BusinessDocument" type="BusinessDocumentType"/>
>         <xsd:complexType name="BusinessDocumentType">
>         <xsd:sequence>
>         <xsd:element ref="Documentation" minOccurs="0"
>         maxOccurs="unbounded"/>
>         <xsd:element ref="ConditionExpression" minOccurs="0"/>
>         <xsd:element ref="Specification" maxOccurs="unbounded"/>
>         </xsd:sequence>
>         <xsd:attributeGroup ref="name"/>
>         </xsd:complexType>
>         *** <xsd:element name="Attachment">
>         <xsd:complexType>
>         <xsd:sequence>
>         <xsd:element ref="Documentation" minOccurs="0"
>         maxOccurs="unbounded"/>
>         <xsd:element ref="Specification" maxOccurs="unbounded"/>
>         </xsd:sequence>
>         <xsd:attributeGroup ref="name"/>
>         <xsd:attribute name="businessDocumentIDREF" type="xsd:IDREF"
>         use="required"/>
>         <xsd:attribute name="mimeType" type="xsd:string" use="optional"/>
>         <xsd:attributeGroup ref="documentSecurity"/>
>         </xsd:complexType>
>         **** <xsd:unique name="Attachment-ID">
>         <xsd:selector xpath="."/>
>         <xsd:field xpath="nameID"/>
>         </xsd:unique>
>         </xsd:element>
> 
> We've updated to allow a user to specify multiple specification 
> references, as we were seeking to have the attachment references as 
> consistent as possible to the business documents. We had lengthy 
> discussions about what an attachment might be (substantive or not, 
> 0...n, could metadata be made available around the attachment). Please 
> review and comment further. We may see more changes in future versions. 
> Thank you.
> 
> >FYI, ECALGA is a B2B electronic commerce specification that adopts
> >BPSS, CPA, and ebMS for electronics and IT industries.  You might be
> >insterested in my article [2] on JEITA's interoperability test using
> >ebXML.
> >
> >[1] Japan Electronics and Information Technology Industries Association,
> >    http://ec.jeita.or.jp/
> >[2] Original Japanese version: 
> >     http://xml.fujitsu.com/jp/column/frontline/ebxml_2.html
> >    English translation:
> >     http://www.fujitsu.com/services/solutions/xml/frontline/XML_ebxml2.html
> >
> >Regards,
> >
> >Yano Keisuke
> >  
> >
> 
>