Search FAQs (headers & keywords work best)

What obligation do users of the papiNet standards have to adhering to the standard?

The goal of the papiNet is to make it as easy as possible for groups who want to use the standard to do so. This goal needs to be balanced with the desire of papiNet to have only a single version of the standard for use by the paper and forest products supply chain. Both of these goals are worthy goals and since papiNet is open to improving and enhancing the standard the question, in return, might be, "What are you trying to achieve by changing the standard for your own purpose?"

Our copyright states, "This document may not be sold, modified, edited, or taken out of context such that it creates a false or misleading statement or impression as to the purpose or use of the papiNet specification, which is an open standard."

We do go on to say that, "Documents may be used as templates for a papiNet implementation. The Presenters grant the right to modify and edit them to fit an actual implementation project provided all copies retain and display the copyright and any other proprietary notices contained in this document. Such modified documents must not be distributed beyond the trading partners implementing or maintaining a papiNet connection." The intent of our copyright is clear, it is to prevent the proliferation of multiple standards that would cause the industry more work.

How stable is the standard?

The measurement of stability, in this particular analysis is, "Who is the source of the standard?" Since initiatives and standards come and go very quickly, this criterion is important.

PapiNet currently has three sponsors, not including the 50 plus member companies who make up these organizations. Two of these sponsors are recognized industry organizations with over 15 years each of existence. The third is a relative newcomer but provides very important European contacts.

papiNet Europe

papiNet started as a project within the Publishing part of the paper industry. A number of major paper suppliers, large German publishers and printers worked together to create a common standard for electronic business transactions. Soon there was a requirement to develop supporting software for handling the transactions via the Internet. This work turned out so well, that it was decided to enlarge the pilot project to encompass other parts of the industry. papiNet Europe currently has 25 suppliers and wide cooperation with customers within the industry.

IDEAlliance

IDEAlliance is the leading global membership organization for advancing the processes of information interoperability and dissemination of knowledge. IDEAlliance accomplishes this by engaging in and supporting the creation and adoption of globally recognized standards for information definition and exchange. Over the last 15 years, IDEAlliance's B2B Standards Committee has been the recognized e-business and Electronic Data Interchange (EDI) standards development body in the North American paper, print, and publishing industry. More information about the IDEAlliance can be found at www.idealliance.org.

American Forest & Paper Association

The American Forest & Paper Association (AF&PA) is the national trade association in the United States of the forest, paper, and wood products industry. AF&PA members include manufacturers of over 80 percent of the paper, wood and forest products produced in the United States. AF&PA acts as the clearinghouse for statistical information, as the leading force in technical, regulatory and policy issues, and as the national voice for the forestry, wood, and paper industries. More information about the AF&PA can be found at www.afandpa.org.

How mature is the standard?

Maturity can be measured in a variety ways: processes for change management, version control, R&D type efforts. Maturity is also likely marked by alliances with key partners (both solutions vendors and customers). By these maturity parameters papiNet fares quite well.

Our change control process is well defined and managed by the Central Work Group. Specific areas that are part of the change process is the statement of the business case, a search for an existing way to achieve the goal, and prior to acceptance the impact is reviewed.

Version control is followed; no changes are introduced in revisions that would prevent users at different revisions of the same version from communicating with each other. Churning of the standard is specifically avoided.

PapiNet performs a variety of R&D activities designed to enhance and improve the standard. The process of identifying new business processes and new market segments to be included in the standard. The appropriate use of new technologies — Schema and developments in ebXML as examples. Convergence with other standards.

While papiNet avoids alliances with software vendors we do publish guidelines for interoperability and work with vendors and customers to achieve conformance. Our users are implementing and vendors are enabling. We can point you to information in this area.

How widely accepted is the papiNet standard?

This is related to the maturity of the standard. Implementations and active projects are a hallmark of the promise that a standard holds long-term. By our latest survey over 80 companies have implemented the papiNet standard.

What are the plans for supporting catalog messages?

papiNet has a message called Product Attributes that is designed to facilitate the communication of product characteristics and the synchronization of product identifies that is associated with a catalog process. papiNet will not be publishing a catalog of paper grades. The Product Attributes message supports the communication of this type of information.

Does papiNet provide a Functional Acknowledgement?

papiNet promotes the ebXML Message Service specification in our Interoperability Guidelines. This specification provides the Functional Acknowledgement that papiNet uses.

Is it possible to report the specifc date a reel is used?

You can certainly report the specific date a reel is used. Currently the time period for the Usage message is controlled by the TimePeriod element in the Header of the message. This permits you to handle the scenario of "Reporting Usage for a Given Day". it would require that you send one Usage Message for each day. Our current set-up incents you to report usage on a timely basis, that is daily. This is a good thing.

Can I send multiple documents at the same time?

This is a topic that quite frequently arises and has been the subject of much discussion by the Central Work Group. The major reason that the envelope is structured to support a single business document at a time is because the business model upon which papiNet is based is one that requires that every business document that is sent be acknowledged as being received. This is a requirement associated with non-repudiation. 
 
While in theory a  structure could be set up to support multiple document sends with non-repudiation (an acknowledgement of receipt) implementation of non-repudiation in a multi-document send environment ends up being more complicated than just responding to every sent message ( the business document).
 
There are also other benefits to the individual document per envelope in that it provides the ability to be more responsive. Instead of waiting for more Purchase Orders (as an example) to arrive each one is sent as it arrives.
 
The papiNet envelope does provide the ability to include multiple attachments for a given business document.

Is FTP a supported method of communication?

We fully support FTP as a method of communication for the papiNet Standard.

The papiNet Interoperability Guidelines (IOG) discusss the common elements related to the packaging of the message. The IOG deals with the packaging of the message and attachments and not with the message service that is used to manage the communication of the message.

You can view a message service as a wrapper around the particular protocol that is used to transmit the message (HTTP, FTP, SMTP). The IOG does provide some information aboutİthe functionality of a "good" message service but it does not get into how a particular message service should operate or what communications protocols it should support. A message that is packaged according to papiNet IOG can be sent via any communication protocol.

A message service that is papiNet compliant does not need to support all communication protocols (there areİothers besides the ones mentioned above). We can draw the interoperability line at any point we want to. We've chosen to draw it outside of the message service box. (You can refer to the papiNet Interoperability Guidelines for a nice graphic of the interoperability horizon.)

How do I implement the namespaced version of the papiNet Standard

Even before you begin to use the namespaced version of papiNet you can begin to prepare for namespaces. When you start to use namespaces in a papiNet environment you will be dealing with two namespaces; one for the envelope and another for the papiNet standard.

You will want to use the suggested namespace prefix when referencing items in the papiNet envelope. This will permit you to use a blank namespace prefix for items in the payload (the papiNet standard business documents). As the papiNet envelope was only introduced along with the namespaced version of the papiNet standard business documents this approach should not have any backwards compatibility issues.

We can slice and dice your programming environment in a couple of ways:

  1. XSL, XSLT, and XPath directives that are not embedded in programming statements
  2. XSL, XSLT, and XPath directives that are embedded in programming statements
  3. XML Document program directives that use classes, objects, and methods that treat the document as an XML instance
  4. Program directives that operate on the XML Document as if it were a text document.

Let's quickly review these one-by-one.

  1. XSL, XSLT, and XPath directives that are not embedded in programming statements
    • These should work fine with a papiNet business document that uses a blank namespace prefix.
  2. XSL, XSLT, and XPath directives that are embedded in programming statements
    • While these statements should not require any modifications you may need to supply information to the programming directive to cross-reference the namespace to the namespace prefix. In the some environments this is supported through a "namespace manager".
  3. XML Document program directives that use classes, objects, and methods that treat the document as an XML instance
    • The handling of an XML document with a namespace and without a namespace is different. The good news is that the changes are usually isolated and not difficult to manage. They are oriented towards the correct association of the schema with a namespace.
    • Once again, look for a class that support "namespace management" that needs to be supplied to the XML Document processing class.
  4. Program directives that operate on the XML Document as if it were a text document.
    • This scenario would exist if you are using programs written by people who have resisted using XML technologies. These programs will most likely not handle namespaces transparently. The good news is that this scenario is extremley uncommon.

How do I test papiNet using a locally stored schema?

We'll discuss this topic from a namespaced version. (For you no-namespace users skip ahead to the end to find out how to do a knowledge conversion to the no-namespace version approach.)

Before dealing with the stated topic of this FAQ let's first quickly discuss 'absolute" and "relative" references. An absolute reference points to a specific location.  For example:

A practical example of a relative reference can be found by looking at any main papiNet schema. In that schema you will find a statement"

  • <xs:include schemaLocation="papiNetCommonDefsV2R40.xsd"/> - this is a relative reference, your programs will look for the common definitions file in the same location where it found the main papiNet schema. (relative location references can have more complex navigation - preceeding dots and slashes to move from one directory to another relative to the main file.

Moving on.

 

By using one of the "file:\\" absolute approach shown above you can indicate that you want to use a locally stored schema. Theoretically you can indicate that the envelope is stored at an "http:\\" location and the papiNet schema is stored at a "file:\\" location but it would probably be easier to copy the envelope to your local hard drive. If you leave out the "file:\\" prefix your system will the location as being relative to the last location information it received.

Now, this approach is usually used when doing testing because in your production environment you will need to supply a programmatic alternative to the references specified in the schema.

If you are a no-namespace version user make the following modifications to the information above:

  1. When we speak of "schemaLocation" convert that to "noNamespaceSchemaLocation" (except in the includes statement)
  2. "schemaLocation" uses a name-value pair of (namespace) - (schema location), in the no-namespace environment this is only a (schema location) value
  3. All discussion of absolute and relative references apply equally to the no-namespace environment

How do I include a non-XML attachment in the papiNet envelope?

The papiNet envelope contains an Attachment element that can be used to communicate any sort of information. The Attachment should be supplied in Base-64-encoded binary format. An identifier for the attachment can be given in the attribute AttachmentIdentifier. Many attachments can be included because the Attachment element is repeatable.

Will new versions be backward compatible with previous version

Releases are compatible with releases at the same version level. However, by definition a version would not be compatible with an earlier version because the decision to announce a new version would be based on the need introduce new functionality that would be incompatible with the earlier releases.

An example of a change that would, most likely, result in a version change would be the introduction of ebXML core components or for that matter convergence with any of the up-and-coming standards (a far off version change that is currently not in our horizon).

Examples of changes that would result in a new release but not a new version would be the addition of an additional constraint to an enumerated list or the introduction of an optional element or attribute.

How often are the release cycles?

During the heyday of papiNet development by design we do not introduce more than two releases in a year. This schedule was maintained to balance the desire to not churn the standard and to deliver new messages in a timely fashion.

papiNet has achieved its initial charter, to deliver messages supporting the full supply chain. Our efforts now are to ensure that the standard is implemented and to enable market segments to fully define their product characteristics. Our goal is to publish a new release once a year.

What is the change process for papiNet?

Changes arrive from a variety of sources. As papiNet is an open standard anyone can submit a request to improve the standard. Changes are categorized and organized by the Change Control Group and in the cases where the functionality exists but in a different fashion this is communicated back to the person requesting the change.

We have found that changes fall into distinct categories:

  • The need to add a constraint to an existing attribute. Unless there is a gross error in the requestor's logic this type of change does not usually pose an issue and is suitable for inclusion. These changes do not require a version change.
  • The need add an optional element or attribute. Once again, unless there is a gross error in the requestor's logic this type of change does not usually pose an issue and is suitable for inclusion. These changes do not require a version change.
  • The need to change a required element or attribute to optional. While this type of change would not require a move to a new version we do look at these requests closely. PapiNet does take positions on acceptable and unacceptable business processes. While these stands can lead to controversy we believe that the benefits to the industry of a consistent process outweigh the loss in flexibility. We do not make these decisions arbitrarily, we seek industry input.
  • The need to add a required element or attribute. Since this type of change would prevent (cause confused expectations) between users at different schema this type of change would result in a version change. This would be done only after we followed the due diligence process associated with validating a change request.
  • The need to change an optional element or attribute to required. This type of change would also require a version change and would be subject to the same due diligence process.
  • Gross changes to an existing element. While these are rare occurrences the issue does arise. We attempt to mitigate the impact through various design techniques. Because of the way in which these types of changes are discovered (a need for a new message is identified with the resulting need to change an existing element) the timing of this change can be integrated with other scheduled changes.
  • New messages. Interestingly enough new messages very seldom require a new version. The papiNet common definitions are robust enough to handle new uses.

Changes are reviewed at every Main Work Group meeting which means at the current schedule every six weeks. There is nothing to prevent us, if and when meeting frequency decreases, from reviewing changes through logical meetings as opposed to meeting physically. With our release cycle of every six months a change would then be populated to the broader industry at that time. Currently, as many of the papiNet implementations are between a small controlled circle the change can be introduced into the trading environment before the new release is published. There are risks associated with this type of behavior but they are manageable.

How can my company influence the standard?

You have the prospect for influencing the standard whether you are a member or not. We pay attention to the feedback that is provided by members and non-members. Additionally, we truly are interested in the penetration of the papiNet standard throughout the entire paper and forest products supply chain.

What do we have to purchase to begin using papiNet?

The standard is completely free for use by anyone. Additionally papiNet supplies stylesheets for most messages.

The benefits of membership in papiNet are significant. Participation in the Segment Implementation Groups is a key benefit and you would be missing out on some very helpful tools. Joining papiNet saves you time and money and allows you to better spend your time as you are not reinventing the wheel.

How will the papiNet standard integrate with my current environment?

  1. This answer speaks to papiNet as an XML standard and also its ability to be mapped to EDI.
    papiNet is developed using XML and as such it will readily fit into any environment that is all ready using this language. Functionality within the XML language (namely XSLT) allows any papiNet document to be mapped to a corresponding EDI document. There are also third-party service providers who can perform this service.
  2. This answer speaks to papiNet's use with other middle ware packages.
    Since papiNet is developed using standard XML techniques a message received in XML form can be managed by any middle ware package that is XML compliant. Our early implementations have taken place using a variety of packages and tools.
  3. This answer speaks to the use of papiNet in process and organizational relationships.
    While papiNet is written to be as broad and all encompassing as possible there are cases where a particular business process is suggested. For example, papiNet is designed in such a way as to not allow a Purchase Order for an "as defined" product (one in which the specifications are included, for the first time, in the Purchase Order) the thought being that this approach would most likely need to support a request-reply dialogue that is more appropriately handled by the RFQ and RFQ Response. We view this as a benefit to the industry in that it sets expectations and limits what needs to be defined in any given process. The intent is not to restrict interaction but to focus it on the correct business process.
  4. While the EPC Messenger is not a part of the papiNet standard many people still are confused about this. This answer speaks to that confusion.
    Due to historical aspects related to the development of papiNet people frequently assume that the papiNet standard requires the use of a particular messaging service. While this never ever was the case there were cases where messaging services that were used by many papiNet users were not compliant with the papiNet interoperability guidelines. Quite frankly because papiNet's interoperability guidelines had not been fully defined. This has changed and the messaging services are compliant. papiNet will continue to broaden the scope of our interoperability guidelines to provide a level playing field between users of dissimilar products.

The history of papiNet will appear in the soon to be released book, "The Complete Unabridged papiNet History". (This is a joke.)

How well are the papiNet messages normalized?

There are definitely instances where elements are not "properly" normalized; however, these are conscious decisions made to improve the readability of a message or to enforce a business process position - that this information is not important in this situation. Party relationships can sometimes communicated using two methods but there are rules for handling these situations.

Is there any ambiguity in the fields or qualifiers?

papiNet has done an extremely good job of defining our elements and terms. So there is very little, if any, ambiguity.

Are DTD versions of the standard available?

papiNet does not publish a DTD version of the standard. Most tools that users would use have the ability to create a DTD from a Schema.

Is papiNet translated into other XML dialects?

While we do not provide other versions of papiNet (XDR, Biztalk, .Net compliant) we work to ensure that papiNet can be translated into these other dialects easily. Please bring any issues to our attention.