RNIF Technical Advisory #B DraftRelease 01_02_00

Technical Advisory B

Modular PIP Reference - Use of XML Schemas

Specification Information

Name RosettaNet Implementation Framework V1.1 & V2.0

Version Issue 01.00.00

Publication Date 2 June 2004

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

Table of Contents

1 Document Management............................................................................................ii

1.1 Legal Disclaimer................................................................................................. ii

1.2 Copyright .......................................................................................................... ii

1.3 Trademarks ....................................................................................................... ii

1.4 Related Documents............................................................................................. ii

1.5 Purpose............................................................................................................. ii

1.6 Scope...............................................................................................................iii

1.7 Conformance Statement ......................................................................................iii

1.8 Document Conventions ........................................................................................iii

1.9 Document Version History ....................................................................................iii

1.10 Acknowledgement........................................................................................... iv

1.11 Approvals ...................................................................................................... iv

2 Introduction ............................................................................................................1

2.1 Terms ...............................................................................................................1

2.2 Issue ................................................................................................................1

3 Modular PIP Reference – Use of XML Schemas ..........................................................2

3.1 Context of Modular PIP Production .........................................................................2

3.2 How RNIF should be read with regards to Modular PIP Release....................................2

3.3 Sections in RNIF 2.0 Specification Explicitly Discussing XML DTDs ...............................4

3.4 Sections in RNIF 1.1 Specification Explicitly Discussing XML DTDs ...............................8

3.5 Additional Sections in RNIF 2.0 Focusing on RosettaNet Business Message Components 10

3.6 Additional Sections in RNIF 1.1 Focusing on RosettaNet Business Message Components11

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

1 Document Management

1.1 Legal Disclaimer

RosettaNet™, its members, officers, directors, employees, or agents shall not be liable for any

injury, loss, damages, financial or otherwise, arising from, related to, or caused by the use of this

document or the specifications herein, as well as associated guidelines and schemas. The use of

said specifications shall constitute your express consent to the foregoing exculpation.

1.2 Copyright

stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical,

photocopying, recording, or otherwise, without the inclusion of this copyright notice. Any derivative

works must cite the copyright notice. Any public redistribution or sale of this publication or

derivative works requires prior written permission of the publisher.

1.3 Trademarks

RosettaNet, Partner Interface Process, PIP and the RosettaNet logo are trademarks or registered

trademarks of "RosettaNet," a non-profit organization. All other product names and company logos

mentioned herein are the trademarks of their respective owners. In the best effort, all terms

mentioned in this document that are known to be trademarks or registered trademarks have been

appropriately recognized in the first occurrence of the term.

1.4 Related Documents

• RosettaNet Implementation Framework: Core Specification 2.0 [RNIF20]

• RosettaNet Implementation Framework: Core Specification 1.1 [RNIF11]

1.5 Purpose

RosettaNet Implementation Framework (RNIF) 2.0 [RNIF20] and 1.1 [RNIF11] either implicitly or

explicitly describe the release and usage of XML Document Type Definitions (DTDs) as the single

normative form for the structure and content of business documents or RosettaNet’s Partner

Interface Process (PIP) specifications.

Despite direct reference in Appendix E: Anticipated Futures, section E.1: Use of XML Schema of

RNIF 2.0 and section 2.2: RosettaNet Message Guideline Format of RNIF 1.1 in terms of using XML

Schema as the next maturing XML technology, a direct conflict is created between RosettaNet and

partners’ by the release of Modular PIP specification.

As such, this Technical Advisory (TA) intends to clarify confusion surrounding the release of

Modular PIPs, and strengthening both sections mentioned above in the usage of XML Schema as a

normative form for PIP specification under the Modular PIP Architecture.

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

1.6 Scope

This document contains information describing enhancements to the RNIF 2.0 and RNIF 1.1

Specifications regarding the inclusion of XML Schema as a valid normative form for the structure

and content of business docume nts or PIPs.

It also intends to strengthen Appendix E: Anticipated Future, section E.1: Use of XML Schema of

RNIF 2.0 and section 2.2: RosettaNet Message Guideline Format of RNIF 1.1.

This document is NOT applicable on RNIF 2.0 and RNIF 1.1 sections that provide detailed technical

specifications on RNIF Header Structure and Format Specifications. A separate Technical Advisory

is planned to address these aspects.

At the time of this release, RosettaNet is planning a separate RNIF Technical Advisory (TA) that will

specifically address XML Schema conversion on RNIF Header Structure and Format Specifications

which will include release of XML Schema based RNIF 2.0 and RNIF 1.1 Headers and Format

Specifications.

Section 3.5 and 3.6 of this document provides a list of parts identified in RNIF 2.0 and RNIF 1.1 as

sections that could possibly be covered under the proposed Technical Advisory detailing changes to

RosettaNet Business Message Components.

1.7 Conformance Statement

Compliance to the enhancements described in this advisory is mandatory if Modular PIPs are

implemented in an RNIF 2.0 or RNIF 1.1 implementation. Applications that conform to this TA

MUST still conform to all requirement of [RNIF20] and [RNIF11], whichever is relevant.

1.8 Document Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,

“MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.9 Document Version History

Version Date Update Information

Issue 01.00.00 02 June 2004 Initial Release

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

1.10 Acknowledgement

RosettaNet acknowledges the following individuals for contributing towards this document.

Content contributors:

Kamarul Zaman Abdul Rashid (on loan from Intel)

Reviewers:

Suresh Damodaran (on loan from Sterling Commerce)

Hussam El-Leithy (RosettaNet)

Annabelle Marlow (RosettaNet)

RosettaNet wish to recognize the following for their significant participation in developing this

Technical Advisory thru the feedback cycle.

Elvina Hendrata (HP)

Brian Magick (HP)

Pierre-Emmanuel Nuiry (STMicroelectronics)

Art Ploeger (Cisco)

Pete Wenzel (SeeBeyond)

1.11 Approvals

Title Name Signature (or type name) Date

Chief

Technologist

Suresh Damodaran Approved -SD 23May2004

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

2 Introduction

This Technical Advisory (TA) prescribes changes to the RosettaNet Implementation Framework

(RNIF) 2.0 [RNIF20] and 1.1 [RNIF11] in order to support the adoption of XML Schema as the

normative specification format.

2.1 Terms

The terms, RosettaNet Business Document (RNBD) and Partner Interface Process (PIP), are defined

in RNIF 2.0 and RNIF 1.1 respectively.

2.2 Issue

This Technical Advisory is a response to the need to clarify the usage of XML Schema as the next

evolving XML language to define RosettaNet PIPs.

Despite the direct references in Appendix E: Anticipated Futures, section E.1: Use of XML Schema

of RNIF 2.0 and section 2.2: RosettaNet Message Guideline Format of RNIF 1.1 in terms of using

XML Schema as the next maturing XML technology, the explicit references to “DTD” in the RNIF

specifications has caused confusion among implementers.

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

3 Modular PIP Reference – Use of XML Schemas

3.1 Context of Modular PIP Production

RosettaNet Board Members and voters approved the new PIP Specification Format in September

2002. Two samp le PIPs, 3C3 and 4A1, were created by the PIP Specification Format (originally part

of Next Generation Architecture Foundational Program) team to facilitate evaluation and approval

of the new format.

Modular PIPs will be created primarily for new PIP development under new Milestone programs.

Existing Monolithic PIPs will not be reworked and published in Modular format unless they come up

for major revision/maintenance. Another scenario in which a Modular format may be created for a

Monolithic PIP is when the creation of Modular PIPs for a new domain necessitates the rework of

one or more Monolithic PIPs.

Differences between Monolithic and Modular PIP structures are explained below:

Monolithic Modular

PIP Service Content Structure Monolithic PIP Service Content

Structure: message guideline +

DTD

XML Schema based PIP Service

Content Structure is still

Monolithic, and is created by

composing Universal Structures

and Domain Models

Message Exchange and

Message Control Parameter

Specification

UML + text (for 2 party only) ebXML BPSS XML Schema

compliant (for 2 party)

Information Sharing Model

Document interchange model Document interchange model

Implementation Human Labor Intensive Machine Process-able

3.2 How RNIF should be read with regards to Modular PIP Release

In RNIF 2.0: Appendix E: Anticipated Futures lists a set of future technological developments,

which RosettaNet MAY adopt based on suitability and timeline.

On that note, specifically to section E.1 Use of XML-Schemas, RosettaNet with the publication of

this Technical Advisory states its official strategic announcement on the usage of XML Schemas as

an added normative format to XML DTD. Over the long term, XML Schema will replace DTD, as

more PIPs are released under the Modular PIP architecture.

As such, all sections (listed in Section 3.3 and 3.4 of this TA) in RNIF should be read as “XML

Schemas or DTDs” whenever an occurrence of the phrase “Document Type Definitions (document

type definitions)”, “XML DTDs” or “DTDs” is encountered, and “XML Schema or DTD” whenever an

occurrence of a phrase “DTD” or “Document Type Definition (document type definition) is

encountered.

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

Further to the above, subsequent occurrences of the phrase “XML DTDs and [associated] Message

Guidelines” or “DTDs and [associated] Message Guidelines” should be read as “XML Schemas or

DTDs and [associated] Message Guidelines.”

Additionally, for certain sections in RNIF that requires detailed para-phrasing and revised

recommendations to support XML Schema, Section 3.3.1 and 3.4.1 in this document lists required

extensions for RNIF 2.0 and RNIF 1.1 respectively. As such, previous find-replace advisory MUST

NOT apply.

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

3.3 Sections in RNIF 2.0 Specification Explicitly Discussing XML DTDs

List of sections in RNIF 2.0 Specification identified to be explicitly referencing to XML DTDs as the

single normative format.

Section Number Section Label

1. 1 Introduction

2. 1.2 Technical Background

3. 1.2.2 PIPs and the Implementation Framework

4. 1.2.2.1 Action and Signal Messages

5. 1.2.4 PIP Metamodel

6. 1.2.4.3 Implementation Framework View (IFV)

7. 2 Technical Specifications

8. 2.1 RosettaNet Business Message Components

9. 2.1.2 XML Usage

10. 2.1.2.2 Validation Rules [Refer Section 3.3.1]

11. 2.1.2.4 DTD Naming, Pathname Specification and Versioning

[Refer Section 3.3.1]

12. 2.1.4 Payload Components

13. 2.1.4.1 Service Content [Refer Section 3.3.1]

14. 2.1.4.3 Referring to Attachments from within Service Content

[Refer Section 3.3.1]

15. 2.1.4.4 Shipping Non-RosettaNet Se rvice Content in the Payload

16. 2.5 Business Signal Specifications & Process Control PIPs

17. Appendix B Required PIP Metamodel Changes

18. B.7 IFV and Agent/Service References

19. Appendix C IFV Mapping From BOV and FSV

20. Appendix E Anticipated Futures

21. E.1 Use of XML-Schemas [Refer Section 3.3.1]

22. Appendix G References [Refer Section 3.3.1]

23. Appendix H Glossary [Refer Section 3.3.1]

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

24. Technical Advisories for RNIF 2.0

3.3.1 Sections in RNIF 2.0 Specification Requiring Para-Phrasing

Section Number Revised Phrase

2.1.2.2 Validation Rules

All elements MUST be validated against the DTD or the XML Schema that contains it, based on standard grammer validation

rules.

The following is the minimum level of validation that is required on each of the XML body parts, namely, the Preamble, the

Delivery Header, the Service Header, and the Service Content.

1. The XML document MUST be compliant with its corresponding XML Schema or DTD.

2. For DTD based elements:

a. Where an element’s data type and/or length is specified in the corresponding RosettaNet Message Guideline, the

element MUST be validated against these specifications.

b. Where an element’s allowed list of values is specified in the Entity Instance list in the corresponding RosettaNet

Message Guideline, the element MUST be validated against these specifications.

c. Where the cardinality specification of an element in the Message Guideline is different from the corresponding

specification in the DTD, the specification in the Message Guideline is more accurate and MUST be adhered to.

d. Where the sequence or naming of an element in the Message Guideline is different from the corresponding

specification in the DTD, the specification in the DTD is more accurate and MUST be adhered to.

3. Where a dictionary is present and the PIP requires Dictionary Validation, the Service Content MUST be validated against

the dictionary as a part of action performance.

4. If a message does not follow one or more of the above rules, then it MUST be deemed invalid.

2.1.2.4 XML Schema or DTD Naming, Pathname Specification and Versioning

All XML documents which are based on specifications that include an associated Document Type Definition (DTD) MUST

reference the DTD by specifying the doctype element. Meanwhile for XML documents which are based on XML Schema,

reference MUST be made using schemaLocation attribute.

The name of the DTD or the XML Schema file as published by RosettaNet MUST be specified, and MUST NOT be renamed

differently. Either the doctype element or the schemaLocation attribute MUST NOT specify any additional URL qualifiers that

refer to a specific location where the DTD or XML Schema file exists. But in the case of XML Schema, schemaLocation attribute

MUST have the targetNamespace of the Schema as the prefix before the original Schema file name delimited with a singe

space.

Recipients of RosettaNet XML messages are responsible for configuring their systems to find the appropriate DTD file.

Example : <!DOCTYPE Preamble SYSTEM "Preamble_MS_V02_00.dtd">,

<Preamble xmlns="http://www.rosettanet.org/RNIF/V02.00" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.rosettanet.org/RNIF/V02.00 Preamble_MS_V02_00.xsd">

2.1.4.1 Service Content

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

The Service Content part of the payload contains business content that is in XML format. The Service Content is always

either an action message or a signal message. The DTDs for all signal messages are specified by RosettaNet. The XML

Schemas or DTDs for PIP action messages MAY be specified by RosettaNet or by other standards bodies that have been

sanctioned by RosettaNet. PIPs must identify which are the allowed standards body(ies) that can supply content in the

given PIP.

2.1.4.3 Referring to Attachments from within Service Content

As mentioned above, attachments to Service Content are sent as separate MIME body parts in the same RosettaNet

Business Message. This method packages and ships the business content and attachments together. However,

RosettaNet recognizes that it sometimes would be necessary to refer to attachments from within the Service Content.

Since action messages (specified by RosettaNet or otherwise) are defined independently of the RosettaNet

Implementation Framework, RNIF 2.0 defines a standard mechanism to refer to attachments from within XML Service

Content documents and leaves it up to the Service Content DTD or XML Schema developers to make use of this

mechanism.

Each attachment MUST be identified by the MIME header “Content-ID” in the RosettaNet Business Message. All XML

elements that could refer to attachments MUST have the attribute “href” defined as one of the attributes for the XML

element.

For example (DTD):

<!ELEMENT AnyElement (#PCDATA)>

<!ATTLIST AnyElement

%miscAttribute s;

href CDATA #implied)>

Additional example (XML Schema):

<xs:element name="anyElement"

type="tns:anyElementType"/>

<xs:complexType name=" anyElementType ">

<xs:attribute name="href" type="xs:anyURI" />

</xs:complexType>

Appendix E E.1 Use of XML-Schemas

On September 2002, RosettaNet Board Members and voters approved a strategic direction to start defining PIP IFV

Specification based on W3C XML Schema. This marks an official direction from RosettaNet to move away from XML DTD

based specifications. Two sample PIPs, 3C3 and 4A1, were created by the PIP Specification Format (originally part of

Next Generation Architecture Foundational Program) team to facilitate evaluation and approval of the new format.

Known as Modular PIPs, this new set of specifications will be created primarily for new PIP development under new

Milestone programs. Existing Monolithic PIPs will not be reworked and published in Modular format unless they come up

for major revision/maintenance. Another scenario in which a Modular format may be created for a Monolithic PIP is when

the creation of Modular PIPs for a new domain necessitates the rework of one or more Monolithic PIPs.

As the specifications mature, RosettaNet will continuously strive towards increased improvements in the PIP IFV

deliverables in terms of increased automation and machine process-able capability. It should be noted that this would

not impact the physical encoding of the Action or Signal messages but, provides more robust specification of the

schemas for these specifications that support more automated schema validation to the extent facilitated by the schema

standards.

Appendix G References

§ Modular PIP Specification Package User Guide, RosettaNet, 2004. (Source: http://www.rosettanet.org)

§ XML Schema Part 1: Structures, W3C Recommendation. Henry S. Thompson (University of Edinburgh), David Beech

(Oracle Corporation), Murray Maloney (for Commerce One), Noah Mendelsohn (Lotus Development Corporation).

Worldwide Web Consortium (W3C), May 2, 2001. (Source: http://www.w3.org/TR/xmlschema-1/)

§ XML Schema Part 2: Datatypes, W3C Recommendation. Paul V. Biron (Kaiser Permanente, for Health Level Seven),

Ashok Malhotra (Microsoft, formerly of IBM). Worldwide Web Consortium (W3C), May 2, 2001. (Source:

http://www.w3.org/TR/xmlschema-2/)

Appendix H

Glossary

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

Modular (PIP) Specification: In September 2002, RosettaNet Board Members and Voting Community approved the

XML Schema format (also known as Modular) for its standards. The message still includes context and action

information but it is built from a library of data structures. There are more consistent in structure and content. The PIP

message is characterized with XML schema and is machine readable; hence the standards metadata can be

automatically read, configured and aligned. The Modular PIPs are designed and developed based on an Explicit Business

Information Model. In other words, the Modular PIPs are built out of reusable objects, designed in terms of small

cohesive core objects to provide consistent syntax and semantics

Monolithic (PIP) Specification: A Monolithic PIP message includes both context and action information. The message

is characterized with DTD and human readable documents, hence, the standard metadata of the PIP must be manually

read, configured and aligned

XML Schema: specifies the XML Schema definition language, which offers facilities for describing the structure and

constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility. The schema

language, which is itself represented in XML 1.0 and uses namespaces, substantially reconstructs and considerably

extends the capabilities found in XML 1.0 document type definitions (DTDs)

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

3.4 Sections in RNIF 1.1 Specification Explicitly Discussing XML DTDs

List of sections in RNIF 1.1 Specification identified to be explicitly referencing to XML DTDs as the

single normative format.

Section Number Section Label

1. 1 Introduction

2. 1.2 Partner Interface Process (PIP) Guidelines [Refer Section 3.4.1]

3. 2 Partner Interface Process(PIP) Specifications

4. 2.1 PIP Business Message Structure

5. 2.1.3 Message Content

6. 2.2 RosettaNet Message Guideline Format [Refer Section 3.4.1]

7. 6 Technical Compliance

8. 6.1 Compliance with PIP Specifications

9. Bibliography – Other Documents [Refer Section 3.4.1]

10. Glossary [Refer Section 3.4.1]

11. Technical Advisories both for RNIF® 1.1

3.4.1 Sections in RNIF 1.1 Specification Requiring Para-Phrasing

Section Number Revised Phrase

1.2 Partner Interface Process (PIP) Guidelines

4. Finally, the PIP “blueprints” are used to create a PIP specification, which includes specific business message guidelines to

carry out the business processes contained in the PIP and corresponding DTDs for each message guideline. Additionally,

RosettaNet is also publishing Modular PIP Specifications utilizing XML Schema.

Supply chain companies and RosettaNet solution partners that wish to create open, interoperable, networked applications

need to adhere to these specifications, which are distributed in both human-readable and machine-readable forms. However,

the machine-readable versions (i.e., XML DTDs) are not complete specifications, due to the limitations of DTDs themselves.

Hence the complete specifications only exist in the human-readable PIP specification and accompanying message guidelines

(HTML format). Neverthless, in an attempt to increase machine-readability and modularized PIP components RosettaNet

started to publish Modular PIP Specifications for new Milestone Programs which will allow RosettaNet member companies to

create soultions that can be rapidly configured to changing supply chain business models.

2.2 RosettaNet Message Guideline Format

Modular PIP Reference -

Use of XML Schemas Issue 01.00.00 Technical Advisory B

Specification of message guidelines is in human-readable form, using RTF and HTML formats for Monolithic PIPs. Additionally,

message guidelines are provided in machine-readable formats. The preferred format is XML Schemas or XML DTDs. Message

vocabulary comes from RosettaNet dictionaries; each message guideline has its own DTD or XML Schema.

Especially for DTDs, while it allows partners to determine if a message structure is valid, they will not allow partners to

determine if a message is valid with respect to a message guideline for a business document (captured in the RosettaNet

business document UML model). The reason is that DTDs aren’t as rich as the UML and OC L (Object Constraint Language) that

RosettaNet uses to describe business documents designed during PIP analysis sessions. (Note therefore that the only complete

specification of a message guideline is in the human-readable RTF and HTML formats for Monolithic PIPs.)

Although DTDs are well understood and there are plenty of parsing tools available to validate the message structures.

However, DTDs alone are not sufficient to validate a message at a higher level, such as semantics that may include

constraints (absence, presence, etc.) on the elements of a message structure. Unfortunately, there are no mature and open

mechanisms for specifying these constraints with commerical off-the-shelf (COTS) tools available today. (Note that schema

validation tools will be able to validate more of the message than DTD validation tools.)

Opposite to DTDs, as for Modular PIPs the development in XML Schemas has enabled extended capabilities to contain rich

information such as message vocabulary, constraints, data types and choreography. XML Schema enables functionalities that

could validate message at a higher level, such as semantics that may include constraints, restrictions, enumerations etc. on

the elements of a message structure, thus increasing automation and machine-processable capability.

Supply chain partners should review their trading partner agreements in this respect. The UN/EDIFACT and American Legal

Association recommend that partners agree on the point at which a message is legally considered "received" i.e. the point at

which you could send back an acknowledgement of receipt. Such agreement must take into account what partners can do with

tools and must be human-validated at this point. RosettaNet is separately working on recommendations for member Trading

Partner Agreements.

Bibliography – Other Documents