Issue 8011: Add complex type Section_context (plm-ftf) Source: (, ) Nature: Enhancement Severity: Significant Summary: Add complex type Section_context according to the requirements described in the VDA Recommendations for the Exchange of digital Engineering Change Requests (ECR). Proposed solution: <xs:complexType name="Section_context"> <xs:complexContent> <xs:sequence> <xs:element name="Msg_type" type="xs:string"/> <xs:element name="Dunsnr" type="xs:string"/> <xs:element name="Interactionid" type="xs:string"/> <xs:element name="Newinteractionid" type="xs:string" minOccurs="0"/> <xs:element name="Interactionscenarioname" type="xs:string"/> <xs:element name="Messagename" type="xs:string"/> <xs:element name="Sequenceno" type="xs:integer"/> <xs:element name="Iscomplete" type="xs:boolean"/> </xs:sequence> </xs:complexContent> </xs:complexType> Resolution: Revised Text: Actions taken: December 23, 2004: received issue Discussion: ECR related use cases are subject to further discussion. Currently, a draft version of spacification for the problems described here is available. Description from VDA 4965-1 (Review Version January 2005), Section 5.3.3 translated into plain English: Data object Description (Type/Format, Example, Meaning) DUNSNR Type: Integer, Format: 9 Digits; Example: 315744388worldwide unique code, recognised as standard for identification of companies (DUNS: Data Universal Numbering System). INTERACTIONID Type: String; Format: DUNSNr "/"ECR_ID.ID; Example "717743322/AEA553421"The INTERACTIONID (and the NewInteractionId) identifies in conjunction with DUNSNR of Coordinator and Participant worldwide unique the association of a message and a interaction dialog, e.g. the . einer in Ausführung befindlichen Interaktionsszenario-Messageabfolgen. Wegen dieser Anforderung zur Eindeutigkeit der Zuordnung auf Seiten des Senders und des Empfängers und wegen der Möglichkeit, diese INTERACTIONID im Verlauf der Interaktion wechseln zu können, sollte sich die INTERACTIONID eindeutig dem Aussteller der INTERACTIONID zuordnen lassen; dieser muss zusätzlich dafür sorgen, dass die INTERACTIONID innerhalb seines Unternehmens eindeutig ist.1. Falls dies die erste Message der Interaktion ist, gilt: Der Sender vergibt eine neue InteractionId.2. Falls dies nicht die erste Message der Interaktion ist, gilt: a) Falls in der vorangehenden Message NEWINTERACTIONID = "" war, gilt: INTERACTIONID muss denselben Wert wie die vorangehende INTERACTIONID aus der letzten Message dieses Interaktionsdialogs enthalten. b) Falls in der vorangehenden Message die NEWINTERACTIONID <> "" war, gilt: INTERACTIONID muss den Wert der NEWINTERACTIONID enthalten. NEWINTERACTIONID Typ/Format/Bsp.: wie INTERACTIONIDEnthält den Wert, der ab der nachfolgenden Message als neue INTERACTIONID zu verwenden ist. Falls gleich "" (leerer String), signalisiert dies, dass die bisherige INTERACTIONID beibehalten wird oder dies die erste Message der Interaktion ist. Falls gleich "": , dann enthält INTERACTIONID die bisher gültige INTERACTIONID, und NEWINTERACTIONID eine neue gültige INTERACTIONID, die eindeutig innerhalb des Requesters/Notifiers eine Interaktion mit einem Partner kennzeichnet. Dieser neue Wert muss in den folgenden Messages dieser Interaktion als INTERACTIONID genannt werden (bis dies ggf. erneut wechselt).Die Möglichkeit, die INTERACTIONID zu wechseln, wird je Interaktionsszenario spezifiziert. INTERACTIONSCENARIONAME Typ: String; Werte: "IS1", "IS2", "IS3", "IS4"Der INTERACTIONSCENARIONAME legt ab der ersten Message fest, gemäß welchem Interaction Scenario der nachfolgende Dialog ablaufen soll. MESSAGENAME Typ: String; Werte: "request_details",…Name der Message, vgl. Abschnitt Error! Reference source not found. SEQUENCENR Typ: Integer; Werte: 1, 2, …Sequenznummer, die angibt, um die wievielte Message eines Senders in diesem IS-Dialog es sich handelt. D. h. SEQUENCENR beginnt bei "1", bezogen auf den durch InteractionId/NewInteractionId identifizierten Dialog auf den durch DUNSNr definierten Sender.SEQUENCENR muss (auch bei Rücksprüngen) erhöht werden, sobald ein Sender eine weitere Message in einem IS-Dialog sendet ISCOMPLETE type: Boolean; values: TRUE, FALSEFALSE marks a Message as preliminary stage, e.g. potentially incomplete, sent for informational purposes only, followed by further intermediate but just one Message indicated as final (compare "Exchange of preliminary stages"). If the object is part of a Request-Message, this Message should not be answered by a Respond-Message; if though, only one or more Respond-Messages with IsComplete = FALSE are allowed. A Respond-Message shall follow a Request-Message with IsComplete = TRUE. Respond-Messages with type preliminary may follow, but shall be concluded by a single mandatory Respond-Message with IsComplete = TRUE. The necessary changes to the specification to capture the functionality described in VDA recommendation is subject ot the extensions of PLM Services 2.0. End of Annotations:===== m: webmaster@omg.org Date: 23 Dec 2004 08:41:49 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Günter Staub Company: PDTec GmbH mailFrom: staub@pdtec.de Notification: Yes Specification: Product Lifecycle Management Services (PLM Services) Section: 7. FormalNumber: dtc/04-11-04 (.dtc_04-11-04.pdf.) Version: na RevisionDate: 11/04/04 Page: 584 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Add complex type Section_context according to the requirements described in the VDA Recommendations for the Exchange of digital Engineering Change Requests (ECR). Proposed solution: