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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: RE: Options for BP Spec Schema issue (#76) regarding ID and IDREF s


As per the 2001-04-25 conference call, regarding Issue #76 the resolution is
to adopt Option 5 which specifies the use of optional machine readable
ID/IDREFs in addition to the required human readable name/references.

I suggest that in addition to this approach we go a small step further and
use XPath as the syntax for the reference. This follows ebXML guidelines to
adopt existing W3C specifications where possible and avoids the need to
define a custom naming scheme. 

The advantages to this approach are:
- it uses existing W3C specification for XPath
- tools will more readily be able to process XPath expressions rather than a
custom naming scheme
- it is still human readable by the developers coding the XML directly,
since they understand XPath
- developers using popular XML tools will be able to cut and past XPath
expressions
- we will not have to document the naming convention

The disadvantage (less significant) are:
- XPath is slightly less human readable than the custom naming scheme.

Consider the following real world example:
<Package name="OAGOrdering">
	<BinaryCollaboration name="OrderCollaboration" nameID="b111">
		<AuthorizedRole name="buyer" nameID="r222"/>
		<AuthorizedRole name="seller" nameID="r223"/>
	</BinaryCollaboration>
</Package>
<Package name="ebXMLOrdering">
	<BinaryCollaboration name="OrderCollaboration" nameID="b112">
		<AuthorizedRole name="buyer" nameID="r224"/>
		<AuthorizedRole name="seller" nameID="r225"/>
	</BinaryCollaboration>
</Package>

As currently defined in the spec the name attribute is not required to be
unique, thus allowing reuse of the names Ordering and buyer. To specify the
reference to the buyer AuthorizedRole for the element Performs:
<!-the custom approach -->
<Performs authorizedRole="/OAGOrdering/OrderingCollaboration/buyer"/>

<!-the XPath approach -->
<Performs
authorizedRole='//Package[@name="OAGOrdering"]/BinaryCollaboration[@name="Or
derCollaboration"]/AuthorizedRole[@name="buyer"]'/>

<!-Combination approach -->
<Performs authorizedRole="buyer" authorizedRoleIDRef="r222"/>

It is not required to use the full path specification as shown above, other
forms of XPath expressions could be used as long as they resolve to a single
reference. For example if buyer was unique to the document then the XPath
could have been:
<Performs authorizedRole='//AuthorizedRole[@name="buyer"]'/>

Relative paths are also allowed for example:
<BusinessTransactionActivity fromAuthorizedRole='../
AuthorizedRole[@name="buyer"]'  ... />

Regards,

P.S. I hope to get the updated DTDs as per todays meeting out before
tomorrow morning.

________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069 Note the new number!

 -----Original Message-----
From: 	Kanaskie, Kurt A (Kurt)  
Sent:	Thursday, April 19, 2001 4:46 PM
To:	ebxml-bp@lists.ebxml.org
Cc:	'Karsten Riemer'
Subject:	Options for BP Spec Schema issue (#76) regarding ID and
IDREFs

 << File: BP Spec Schema issue regarding ID and IDREFs (Issue #76).doc >>
All,

As per today's BP Meta Model call, please see attached Word document
detailing the issue and possible options. Please feel free to add to the
Pros and Cons of each option. Hopefully this will help us work through the
issue and come to a resolution.

 <<BP Spec Schema issue regarding ID and IDREFs (Issue #76).doc>> 
Best Regards,

________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069 Note the new number!



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC