PIP FAQ 1. How to use the tag Q. PIP 2A10 uses a tag called . What is the purpose of this tag? How and when do I use it? A. refers to information "chunks" defined in the Information Distribution Agreement (IDA). An information "chunk" can be a list of properties of a certain product class or one or more files providing information on a product class or family of products. If the information provider can provide all the required information at the same time in the same PIP, this tag and the concept of "chunking" provide no useful functionality and can be omitted (it is optional). Sometimes, however, all the information cannot be provided in the same PIP at the same time. For example, in a collaborative development environment, upstream information is available before downstream information, and collaborative partners will want to exchange information as soon as it is available rather than wait until the end of development when all the information is finally finished. In this case, the information defined in the IDA should be arranged in chunks to correspond with their expected availability. These chunks should be labeled in the IDA in some way, such as "batch A, ... batch B ...." or "chunk A, ... chunk B ..." or even simple 1, ..., 2 .... Whenever one of these chunks of information becomes available for distribution, the label for that chunk should be put in the tag and the information required for that chunk put in the rest of the PIP. The receiver of the information will then know which section of the IDA is being fulfilled by the content in the PIP. 2. Database deletions. Q. I have a question regarding 2A9 refresh, and 2A10 push/change information. According to what I have read, we are to carry information in these processes notifying the customer of a deleted product. I understand the reasoning for this, and for us it would be a small concern because we typically do not remove parts from our database. However in the case that we do remove a part, there is no way of notifying anyone since it is actually deleted. Have you been involved with discussion on this topic or have any understanding of how other companies are handling this exchange? A. 2A9 is just a query so a query to a deleted item would return something like "info not available." 2A10 is a push and it can be used to synchronize database content in two (or more) companies. If the source of the information wants to delete some items, that company should use 2A10 and specify the items to be deleted (always use the ProductNumber to ensure the right item is selected). You can delete all information on a product or just certain characteristics. To delete, specify GlobalActionCode = "delete". The actual deletion is the responsibility of the backend system. If you want to textually notify your partners that a product has been deleted from their database, put a notice of that fact in the tag. This tag can be very useful for such notifications. Just make sure your partners know that you will be using this tag for that purpose so that they can pull it out and send the information to the appropriate person. If Sony is one of your partners, they will be expecting you to use this tag for this purpose. 3. How to use the GlobalActionCode Q. Both ProductInformation and Property have a GlobalActionCode. What kind of combinations are possible with these two GlobalActionCode-s? For example, if the GlobalActionCode for ProductInformation is "Delete", what GlobalActionCode is specified for the Property-s. Or if the GlobalActionCode for ProductInformation is "Add", can the GlobalActionCode for Property-s contain anything other than "Add"? Please make these various combinations clearer. A. The GlobalActionCode for ProductInformation refers to product itself. If it specifies "Add" that means that the product does not exist in the target database and the product (and its properties) must be added to the database. (In this case, each property to be added would also specify "Add" in the Property GlobalActionCode.) If it specifies "Delete" then the product and all its Property-s must be deleted from the database. (In this case you do not have to list all the Property-s in the PIP, just the ProductNumber to identify the the product to be deleted. Of course, the GlobalActionCode for ProductNumber would also specify Delete.) In all other operations other than product Add or Delete, the GlobalActionCode for ProductInformation would be "Revise" and the GlobalActionCode for Property would specify the action to be performed for that property only, i.e., Add, Revise, or Delete. Q. Suppose you specify Delete for the GlobalActionCode for a Property. The Cardinality for Value is 1..n. Why do you have to specify the Value if you are going to delete the property anyway? A. There are times when a given Property has more than one Value. For example, a multifunction interface chip may have an InterfaceType property with the Values of USB1.1, USB2.0, 1394. We have to have some way to allow the user to delete, for example USB1.1 and leave the rest. Thus the value has to be specified. In most cases, of course, there will only be a single value and you might think that it is redundant to provide a Value when you are going to delete the Property anyway. However it is standard practice to double confirm any delete requests. If the Value in the PIP matches that in the database, it is assumed safe to delete the Property. If the value does not match, there is a synchonization problem between the two databases or the action is being requested by someone who does not know the real facts about the database. In this case the action should be rejected and a suitable error message output from the target database. Q. If a Property has a GlobalActionCode of Add, Revise, or Delete and also specifies a Type code, does the action only apply to the Property Value with that type or does it apply to all typed Values in that Property. A. If a Property contains a typed Value then all the Values in the Property have to be typed. (This is an operational constraint specified in the Message Guidelines.) Any operations on those values must always specify the Type and the operation is performed only on the Value with that Type. Q. If you are using the Position tag to send information (praoperties and/or PIOs) on a single Product in several messages, how do you specify the GlobalActionCode at the ProductInformation level? Is it Add or Revise? A. As mentioned above, the GlobalActionCode for ProductInformation applies to the full set of information about a product. If it specifies Add, then this product does not exist in the database and must be added. So the first time you send any information about a product the GlobalActionCode for ProductInformation must be Add. After that all subsequent messages would be Revise until you want to delete the whole set of information, when the GlobalActionCode would be Delete. Q. When you send information on a product you must always specify a Property that uniquely identifies the Product, like Part Number or Class Name. What GlobalActionCode is used with this unique identifier (access key) the first and all subsequent times? A. The first time any Property is sent, whether unique or not, the GlobalActionCode is always Add. But because the unique identifier (access key) is not ordinary property data it cannot be revised or deleted. Since no Global Action is performed on this data item in all subsequent messages, the GlobalActionCode has no meaning and it is not specified for the unique identifier in all those subsequent messages. This constraint is specified in the Message Guidelines. Q. What is the meaning of the GlobalActionCode-s "Change Request Accepted" and "Request Accepted with Change"? A. The RosettaNet Business Dictionary defines five GlobalActionCode-s. This PIP only uses Add, Revise, and Delete. We don't use the two you mention. I'm not sure what they mean (the Business Dictionary does not define them), but I assume they are replies to a database change request in some other PIP that sends a reply to a database change request. 4. Versioning Q. The 2A10 DTD specifies a Version tag for ProductInformation but this item duplicates other existing version control items. For Product characteristics, the RNTD currently defines XJE001 Data Version Number and XJE002 Data Revision Number, as well as RNP290 Product Version Number and RNP291 Product Revision Number. For PIOs there is another separate Version tag. Duplication of the RNTD property and 2A10 message item will cause confusion to systems. A. This PIP acknowledges four different kinds of version: 1) PIP information version 2) Product information version/revision number (from RNTD) 3) Product version/revision number (from RNTD) 4) PIO version You say that #1 and #2 are identical and that therefore #1 should be deleted. But they are not identical. #1 is the version of the total information package being provided. The information provided may change without a change in the product version number or the product version number may have changed twice or more before a message is delivered describing the change, so it is possible to have an information package version 3 with a product information version 6. This PIP relates to a promise to provide information and this information package version number provides an ability to track the process of fulfilling that promise. The version number of products is a completely different thing and not related to the promise. Deleting this tag will make tracking very difficult. So it cannot be deleted. 5. Use of Space and GlobalLanguageCode Q. Shouldn't these attributes be written as xml:space, xml:lang? A. The RosettaNet PIP style guide requires all words to be spelled out and also has specific capitalization rules. These conflict with the W3C convention you mention in your question but these rules are applied to all current PIPs. Furthermore, GlobalLanguageCode is defined in the business dictionary and is used by other PIPs. So we followed the RosettaNet rules. The computer system will not care which rule is used as long as the rule is used consistently. Still the whole question of the best way to provide support for multiple languages is being studied by RosettaNet's Engineering Department. Until they come to a decision on this point, we should follow current RosettaNet rules. Q. The cardinality for Space is 1 but it has a default value of Preserve. If it has a default value, that means that the user does not have to define it and the cardinality should be "0..1". Why is the cardinality 1 rather than "0..1"? A. Cardinality refers to what must/may be in the message when it is being exchanged. It does not necessarily define what the user or the user's backend system must physically enter into the message. Some items, such as default values, can be automatically added in the machine processing of the message. The cardinality of 1 specifies that a value must exist in the Space attribute during the exchange. Since most people will use the Preserve value, the machine will automatically add it unless you specifically enter a different value. Thus there will always be a value in this attribute during the exchange process and the cardinality for the exchange process is 1. 6. Using Value Type Q. According to my reading of the Constraints for Value and Property, the following example is allowed: (Example 1) 123 456 Conversely, the following example is not allowed: (Example 2) 123 456 It seems to me that Example 1 should also be prohibited. Shouldn't the Message Guidelines have a Constraint to prohibit it? A. You are right. Actually, in rereading the constraints I also noticed a number of clumsy expressions and downright grammatical errors. When the time is convenient, we will have to issue a maintenance release of the Message Guidelines. This problem, however, does not affect the DTD or PIP Specification. 7. Identifying complex interactions Q. My concern is whether the receiving party can understand the format of the message, if the sending party sends the message only indicating that the message is 2A10. I think I need an example to explain. If company A and company B decided to use 2A10 in two ways, one is sending files from A to B and the other is sending product attributes from A to B, B can't know what the received message is for without additional information. How can the computer recognize all these various scenarios? A. The PIP specification says that companies A and B will enter into an agreement (the Information Distribution Agreement) that clearly states exactly what information each partner will provide. Then the message itself clearly states exactly what information is being provided by identifying the agreement and referring to dictionary definitions. In fact, you are not allowed to send any information in the message without referring to a dictionary definition that says exactly what the data is. Yes, the IDA can specify a single scenario or even multiple scenarios and the message can distinguish them using some kind of grouping technique in the IDA and the tag in the PIP. 8. Compressed files Q. I'm thinking that the PIP should implement a mechanism that handles multiple business documents compressed into a single attachment file. A. We have been studying this requirement for some time now, but have not yet found a way to tell the computer both that the file is compressed (i.e., the kind of compression method used) and the FileFormat of each of the files within the compressed file. Perhaps the solution would be to require an ASCII Table Of Contents file at the beginning of the compressed file that then defines itself and all other files in the package as to sequence and FileFormat. Until we can design a standard way to identify these files, you will have to send the files in a non-compressed way. 9. Value format coding scheme (in RNTD) Q. I can't understand the coding scheme used for the value formats. What is the meaning of the characters? AThese value formats are taken from the definition in IEC 61360-1 (4-3-1). Here is a simplification of that definition. Value format Value format is the specification of the type and length of the representation of the value of a data element type. These are specified in the sequence: . 1. Character types used in value formats (These characters are defined ISO/IEC 10646-1, annex A.) a) Non-quantitative data value format types: A = alphabetic, letters only M = mixed, all characters allowed N = numeric, digits only X = alphanumeric B = binary, 0 or 1 b) Quantitative data value format types in accordance with ISO 6093 NR1 = integers NR2 = rational numbers with decimal-mark (reals) NR3 = rational numbers with decimal-mark and exponent-mark (floating point) S = signed (positive or negative) . = decimal-mark E = exponent-mark, base 10: (A)E(B) represents the value Ax10B 2. Field length a) Non-quantitative type The field length of a non-quantitative data value is indicated by a number (e.g. 17). A variable field length starts with two dots. Examples: A..17 N..3 X..33 M..255 B..3 A fixed-field length starts with one space Examples: A 3 N 8 X 17 M 35 B 1 a) Quantitative type The field length of a quantitative data value shall be indicated by a combination of digits and characters (e.g. 3.3ES2). A variable field length shall start with two dots. Examples NR1..4 -> positive integers, up to four digits NR1 S..4 -> positive or negative integers, up to four digits with sign NR2..3.3 -> positive reals, up to 3 before decimal point and up to 3 after NR2 S..3.3 -> positive or negative reals, same as above with sign NR3..3.3ES2 -> floating point, positive, NR3 S..3.3ES2 -> floating point, positive or negative A fixed-field length shall start with one space Examples: NR1 4 -> positive integer, always four digits NR1 S 4 -> positive or negative integers, always four digits plus sign 10. Synchonizing databases Q. On Page 4 of the PIP Specification, it is stated that gPartners may want to use this PIP to synchronize..." Not sure why this statement is in here. RosettaNet manages the pipeline and not what a customer does with the data once they receive it. A. First, all PIPs I have seen "imply" actions in backend systems. If I send you an invoice with 3C3 I certainly expect your backend systems to process the invoice and send me my money. The tags used in the PIP provide the kinds of information necessary to facilitate the backend processing. They don't specify "how" it is done but must provide the mininum essential information to "enable" it to be done. This PIP does not specify "how" to synchronize databases but it provides semantics that allow the two systems to have a common understanding on the status of the information in the PIP. With that semantics the systems do whatever they need to do to realize the pre-agreed synchronization of database content. "How" they do that depends on the solution software they have in-house. Furthermore, keeping the technical information in both partners "in sync" was one of the strongest use cases for this PIP. If this potential ("may" want to) functionality statement were deleted, the explanation would no longer match the requirements defined for this PIP. So this statement clearly states a strong requirement for PIP content and does not define in any way backend processes (other than to request the backend to add, change or delete certain content held somewhere in some form in some schema in some database, a request that is as vague in definitional content as an invoice is).