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] | [List Home]


Subject: Re: ebBP 1/5/2006: freebxmlBP Editor and Notes


Dear Colleagues,

Many thanks for the comments. On January 1, 2006, our new projects
have started and they are keeping us real busy. We will present you info
when we have time to work on ebBP Editor.

Best regards,

Asuman

Monica J Martin wrote:

> Today, I've posted screen shots and abbreviated notes from our call 3 
> January 2006 for the freebXMLBP editor from METU. Many thanks to Ozgur 
> and Yildiray for the demonstration and presentation.
>    Screen shots
>
>        Public site:
>        
> http://www.oasis-open.org/committees/document.php?document_id=16091&wg_abbrev=ebxml-bp 
>
>
>    Meeting minutes
>
>        Public site:
>        
> http://www.oasis-open.org/committees/document.php?document_id=16092&wg_abbrev=ebxml-bp 
>
>
> Here are some questions and observations from the demonstration 
> (evidenced from the questions asked and the functionality we 
> understand may be planned). I encourage the METU team to comment [1].
>
>   1. externalDocDefRef: Are there plans to implement new features that
>      will exist in v2.0.1 Committee Specification (to be voted on this
>      month after brief 15-day review)?  This would include the
>      externalDocDefRef that allows external information to guide which
>      logical business documents are used and how. [2]
>   2. Patterns and operational semantics: Can you provide greater detail
>      on how the editor uses the patterns matrices and operational
>      semantics?  What plans for the tools exist in this area?
>          * In support of the patterns matrices, do you plan to support
>            the quality, document security and other QoS capabilities
>            described? This is actually more than the core schema. For
>            example, two (or more partners) may choose to use the
>            Business Transaction [3] of type BusinessTransactionType. In
>            the patterns matrices (Section 3.4.9.1), the patterns become
>            like templates, where parties select: BT pattern (including
>            request and response), business signals (some signals are
>            required by pattern), non-repudiation of receipt and content
>            (some patterns require these be used), etc. To that end,
>            this likely necessitates more than a core schema can provide
>            or constrain. Taking you example, the Provider and Seller
>            choose the Commercial Transaction of type
>            BusinessTransactionType, business signals are highly
>            recommended and the partners select to use them, and
>            non-repudiation and document security capabilities are
>            required. Note, that I've not included everything. The
>            template that the pattern matrices provide require
>            selections by the participating parties that in essence
>            becomes a profile. [4] In order for the patterns to be used
>            effectively, these guidelines (matrices and resulting
>            profile) are quite important. And may be even more so for
>            the health care domain.  Note these are observations and
>            comments to emphasize their effective use and importance to
>            business transactions in eBusiness. Some constraints or
>            profile items may be:
>                o A Requesting and RespondingBusinessActivity are 
> required.
>                o If a CommercialTransaction pattern is used, the
>                  signals are highly recommended for use. Have you
>                  thought about use of signals other than those defined
>                  by ebBP? This is allowed by the core schema.
>                o Non-repudiation of receipt and content is required.
>                o hasLegalIntent is false by default to encourage
>                  partners to explicit select 'true.'
>                o documentSecurity is required.
>                o Guaranteed delivery is strongly recommended.
>   3. Package: The package element is also important as there you can
>      XInclude another package.  This also allows inclusion of modular
>      process definitions (which is why likely that Sacha asked this
>      question). Are there plans to use this feature in the tool?
>   4. Condition expressions: When XPath is used, does the tool verify
>      the syntax of the expression is valid? My notes are a bit sketchy
>      here.
>   5. Ontologies:
>          * Can you verify if the semantic classes are added to the BT
>            or the BTA? The reason that I ask is that the BTA is more
>            specific to the expectations of the involved parties, i.e.
>            it binds the roles to the BT.  The BT (and the BT pattern it
>            uses) are more generic reusable components. I can see either
>            argument to associate semantic annotations to the BT or BTA
>            but would welcome more details on the functionality and
>            reasoning behind it.
>          * Are the semantic annotations classifed and associated with
>            the process definition in a registry? Where are the semantic
>            details found?
>   6. Patterns:
>          * When you change the pattern minimal requirements, the
>            DataExchange pattern is recommended for use. That gives a
>            user community full reign to add semantics and develop their
>            own pattern within the constraints of the schema definition.
>          * In the case of semantic annotations, I can see that the
>            concrete patterns are used as the ontology tree is outside
>            of the process definition (but provides guidance to its
>            usage). If the syntax of the concrete patterns is changed, I
>            would recommend use of the Data Exchange pattern element
>            (i.e. the semantics and syntax are open for revision).
>            However, I'd encourage other team members to comment.
>
> I would encourage others to ask questions and provide observations 
> too. I feel this is a valuable step for ebBP, the health care domain 
> and METU as well as other domains and user communities. Thanks METU 
> for a job well done. We look forward to seeing more of the CPP and CPA 
> editors.
>
> Happy New Year and again we commend your work thus far and encourage 
> your continued interest in ebBP.
>
> [1] You can do so to myself (monica.martin@sun.com) and/or Dale Moberg 
> (dmoberg@cyclonecommerce.com) directly as likely the list will reject 
> a posting as you are not TC members or observers.
>
> [2] v2.0.1 Public Review Draft, r03 found at:
> Schema
> http://www.oasis-open.org/committees/document.php?document_id=16061&wg_abbrev=ebxml-bp 
>
>
> Schema Documentation
> http://www.oasis-open.org/committees/document.php?document_id=16063&wg_abbrev=ebxml-bp 
>
>
> SignalSchema
> http://www.oasis-open.org/committees/document.php?document_id=16062&wg_abbrev=ebxml-bp 
>
>
> SignalSchema Documentation
> http://www.oasis-open.org/committees/document.php?document_id=16064&wg_abbrev=ebxml-bp 
>
>
> Spec (pdf)
> http://www.oasis-open.org/committees/document.php?document_id=16060&wg_abbrev=ebxml-bp 
>
>
> Spec (doc)
> http://www.oasis-open.org/committees/document.php?document_id=16058&wg_abbrev=ebxml-bp 
>
> Includes technical specification and appendices.
>
> Spec (htm)
> http://www.oasis-open.org/committees/document.php?document_id=16066&wg_abbrev=ebxml-bp 
>
>
> Spec (diff doc)
> http://www.oasis-open.org/committees/document.php?document_id=16059&wg_abbrev=ebxml-bp 
>
> Includes technical specification and appendices.
>
> Spec Appendices (htm)
> http://www.oasis-open.org/committees/document.php?document_id=16067&wg_abbrev=ebxml-bp 
>
>
> Supplements (transforms and comment list)
> http://www.oasis-open.org/committees/document.php?document_id=16065&wg_abbrev=ebxml-bp 
>
> [end]
>
> [3] Business Transaction and Commercial Transaction are of the 
> BusinessTransactionType and are typically for intentional exchange.
> [4] In the future, these templates and a profile could be parsable in 
> XML (IIC and our team starting to work on this).
>


-- 
____________________________________________________________________________
Professor Asuman Dogac   email: asuman@srdc.metu.edu.tr
WWW: http://www.srdc.metu.edu.tr/~asuman/
Director                 Phone: +90 (312) 210 5598, or
Software R&D Center             +90 (312) 210 2076
Department of Computer Eng.       Fax: +90 (312) 210 1004
Middle East Technical University       +90 (312) 210 1259
06531 Ankara Turkey                    skype: adogac



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