ebxml-bp message

Subject: RE: [Fwd: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencingwith id and name issue]

From: Jean-Jacques Dubray <jeanjadu@Attachmate.com>
To: 'Dale Moberg' <dmoberg@cyclonecommerce.com>, Sacha Schlegel <sacha_oasis@schlegel.li>, "Monica J. Martin" <Monica.Martin@Sun.COM>
Date: Thu, 20 Nov 2003 09:56:14 -0800

Title: RE: [Fwd: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencingwith id and name issue]

Sacha:

Even XML Schema has its limitation and cannot allow us to validate any possible rules that constrain the content of an XML document (e.g. unicity of an attribute value across several XML documents).

In 1.1 it was decided to not use xsd:IDREF because it does not works with the concept of package. Instead of using xsd:string, we purposely defined a separate type GUID/GUIDREF (which extends string) to imply a certain behavior for these attributes (generalized ID/IDREF).

I believe that GUID/GUIDREF are employed consistently in 1.1

Martin Roberts may be able to comment more on this aspect.

Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Thursday, November 20, 2003 9:22 AM
To: Sacha Schlegel; Monica J. Martin
Cc: ebxml-bp@lists.oasis-open.org
Subject: RE: [Fwd: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencingwith id and name issue]

Sacha's example maybe shows why we should try to use the GUID/GUIDREF technique consistently.

I had not noticed that the technique had not been employed consistently.

Monica, should this be an Issue, rather than a topic?

I think we should flag it as something to fix.

Dale

> Perhaps, some of the other technical folks can add more detail to
> effectively answer your questions. Can you describe why you feel
"having
> both, the name AND ID, this invites to have logically invalid BPSS XML

> instance documents"?

OK. In BPSS XML Schema 1.01 the data type of the attribute businessDocument of the element DocumentEnvelope is "simply" a xsd:string, which can have any value. The businessDocumentIDRef on the other hand is a xsd:IDREF data type and "must" point to a xsd:ID attribute within the XML document. An attribute of type xsd:IDREF allows the parser to validate if the value given in businessDocumentIDRef is available within the XML document. The parser has no idea about businessDocument as it is "just" a string and that will always be valid.

A real problem occurs if businessDocument and businessDocumentIDRef point to a different BusinessDocument, which hopefully does not happen but would still be a valid XML.

Hope this describes why I feel it could introduce logically invalid (but XML valid) documents.

Sacha

<DocumentEnvelope businessDocument="ABC"
businessDocumentIDREF="ABC_ID" .../>

</RequestingBusinessAcitivty>
...
</BusinessTransaction>
...
</ProcessSpecification>

> ======================================================================
> =================================
> <Snippet>
> Comment from Anders Tell:
> According to the UEB architecture v0.32, line 821-827 the parameters
in
> BPS document are to be considered as default values and a TPA may
> override these. If the TPA does so the TPA values take precedence.
> This indicates a need of being able to uniqually identify all or most
> elements of BPSS documents such as BinaryCollaborations, Transitions,
> Business states etc. I dont think the current spec contains such
statement.
> There are at least two ways to go.
> 1. Add 'ID' identifiers to all specifications elements such as
> adding/moving ID to BusinessState and adding ID to Transition.
>
> Resolution: *_RESOLVED_*
> Check in specification for elements without identifiers - Name -
> attribute with a type of ID, example. Didn't use the XML Schema ID
type
> because when you have a package, the IDs may not be unique. Explain ID

> type must be unique within a given document. In addition, for
packaging,
> this could be handled with an include (see BPSS 1.01, line 1722,
section
> 8.1) that existed for the ProcessSpecification. Also see
> ProcessSpecification in 1.05 (See Section 8.1.15). Package specified
at
> 8.1.19. Have a NAME with an associated NAME ID.......NAME within a
> package (PIP ID in name field for RosettaNet ).
> <Snippet>
>
>
>
>
>
>
>
>
>
> -------- Original Message --------
> Subject:      Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing
with
> id and name issue
> Date:         Thu, 20 Nov 2003 22:19:08 +0800
> From:         Sacha Schlegel <sacha_oasis@schlegel.li>
> To: ebxml-bp@lists.oasis-open.org
> References: <1069336162.850.88.camel@gnaraloo.schlegel.li>
>
>
>
> Hi bp group
>
> OK I have a sample of the name and ID issue:
>
> <ProcessSpecification ...>
>   ...
>   <BusinessDocument name="ABC" nameID="ABC_ID">
>   ...
>   ...
>   <BusinessTransaction name="Trans1" nameID="Trans1_ID">
>     <RequestingBusinessActivity name="ReqBizA" nameID="ReqBizA_ID"
> ...>
>
>       
>       
>       <DocumentEnvelope businessDocument="ABC"
> businessDocumentIDREF="ABC_ID" .../>
>
>
>     </RequestingBusinessAcitivty>
>     ...
>   </BusinessTransaction>
>   ...
> </ProcessSpecification>
>
>
> I did not read up on any "How to engineer XML documents", or UBL's
> "Rules how to write an XML Schema" ...
>
> Kind regards
>
> Sacha
>
> On Thu, 2003-11-20 at 21:49, Sacha Schlegel wrote:
> > Hi bp group
> >
> > Studing the BPSS XML Schema from the "ebXML Business Process
> > Specification Version 1.01" I came across the following issue:
> >
> > Whenever an element X references another element Y there is a) the
> > name
> > (required) of element Y AND b) the ID (optional) of element Y given
as
> > an attribute of the X element.
> >
> > Sample from 1.01 Appendix A:
> >
> > ....actually the sample bpss of 1.01 does not use ID's at all but
> > only names...
> >
> > Looking at the 1.1 BPSS still the name attribute and the ID
> > attribute are in elements.
> >
> > To me, only the ID attribute makes sense as with the ID I can get to

> > the name of the element. Or even having only one, the ID or the
> > name. Having both, the name AND ID, this invites to have logically
> > invalid BPSS XML instance documents.
> >
> > If this issue has been addressed in a post 1.01 version then please
> > ignore this email.
> >
> > Kind regards.
> >
> > Sacha
--
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
4 Warwick Str, 6102 St. James, Perth, Australia
sacha@schlegel.li                www.schlegel.li
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------