Forestry GIS (Geographic Information Services)

Forestry GIS and papiNet

I had the opportunity to spend some time with ESRI (one of the early providers of GIS services and a key current provider).

• Visit http://support.esri.com/index.cfm?fa=downloads.dataModels.gateway for a list of all the data models for all the industry segements.
• Use this link (http://downloads2.esri.com/support/datamodels/Forestry/forestry_datamodel.pdf) for a description of their high level data model,
• At resources.esri.com you can find links to some of their more formal documentation and tools.

Here’s some additional information of note. ESRI had developed something called ArcXML as their contribution to the XML world. ArcXML is no longer being used (you will find numerous mentions of it on the internet, still). OpenGIS is what they are using. As near as I can tell OpenGIS has something they call GML which can be found at http://schemas.opengis.net/gml/3.1.1/base/.

It is important that papiNet make use of the excellent work in the GIS field.

Office OpenXML

Open Office XML formats for Increased Security

While it is a proper point of discussion as to which open XML format for word processing, spreadsheets, and presentations you should or want to use (ODF or Open Office XML) it should not be delaying your migration to an XML format for the office productivity applications. The benefits are too great to delay.

From the standpoint of the print, paper, and publishing industries there has always been a strong emphasis on security. One of the key benefits of migrating to the Open Office XML format is that there are inherent circuit breakers on the inclusion and processing of macros in the Open Office XML formats. There will no longer be a fear of unanticipated behavior taking place.

Microsoft provides adapters that permit you to convert Open Office XML documents into their equivalent binary formats so that they can be managed in you r existing Office 2000 and Office 2003 applications.

Drybridge Consulting provides documentation to papiNet.org

papiNet Documentation in PDF Format

Use this link to be redirected to the papiNet Documentation page.

Latest Build

Embedded Schema Documentation

Scouting the path towards reusable documentation

Back in March of 2008 Drybridge Consulting presented a proposal to papiNet to provide schemas with embedded documentation. Drybridge has performed this process for several North American groups so, the process runs well. The degree to which the embedded schema form of documentation was useful to these groups should be reviewed. While my impression is that the schema with embedded documentation was not widely used this could be due to the ready availability of the printed form and insufficient PR on the availability. The Drybridge Facilitator, which is available as a web-based tool (as well as in a local hard-drive implementation) is used to perform the tasks associated with producing documentation of this type. I would classify the Drybridge Facilitator as an off-the-shelf SaaS (Software as a Service) product.

Moving beyond the question of, “How does papiNet migrate towards embedded schema documentation?”, let’s discuss some of the issues associated with producing embedded schema documentation.

1. papiNet currently has two types of documentation, the data dictionary and the message documentation (business-document documentation). It was originally thought there would be a tighter association between the documentation for the dictionary and the business-document documentation. This has not been the case. There would be, if papiNet decided to produce business-document documentation that included definitions for only the elements, attributes, and enumerations in the particular XML schema. While I believe this would be extremely useful, there has not been a call for this type of documentation. Bottom-line: The more formal business-document documentation can be separated from the process of printing the data dictionary permitting ‘word-processed’ business-document documentation and an embedded-schema documentation approach.
2. Embedding documentation into the schema will result in a schema that is larger and may not be suitable for use in a production environment. Documentation is embedded into a schema by associating xs:documentation and xs:annotation elements with the items that they refer to. Schema parsers will identify and disregard the documentation during the load process. Regardless of whether the additional processing imposes a significant load on a system I felt that the papiNet community would object to being forced to use a schema that is loaded with documentation information. Bottom-line: A version of the schema with embedded documentation and without embedded documentation is required. In my mind this indicates that documentation should exist outside the schema and then be inserted into the schema.
3. papiNet makes extensive use of enumerated lists. There is no way to directly associate a definition with an xs:enumeration item in an XSD. While there are workarounds for this issue they place an onerous burden on the schema editor and dramatically increase the size of the documentation produced. (Essentially, the enumerations would be listed in the definition for the owning-item. Unfortunately, this would result in enumerations showing whenever the item is used in a construct. Currently enumeration definitions only show for the parent data dictionary entry.) Bottom-line: Managing enumeration definitions would require a modification to XML Spy, use of the Drybridge Facilitator, or a relaxation of the expectations of papiNet.
4. The ISS tool links to the data-dictionary using hyper-text-links that have a naming intelligence built in. Documentation produced by XML Spy uses (what I would term) a unique-identifier approach when creating links. I use the same approach when producing the links in the Drybridge Investigator (which produces Schema Difference Analysis). This unique-identifier approach allows the documentation process to disregard the potential for name-collisions. Preventing name-collisions is extremely important. Bottom-line: Since there is no way to predict the unique-identifier that is associated with an element or attribute the link between the ISS tool and the data-dictionary will be lost.

I’ve entitled this email “Scouting the Path” because I believe that producing schema with embedded documentation information is something that should be pursued and I stand ready to help achieve this goal. Please feel free to contact me with any questions.

How to create a papiNet attachmemt

papiNet allows you to communicate attachments in the CreditDebit transaction or in the Envelope. They both allow you to communicate any sort of XML content via an “any” element. We do this by creating an adapter that converts the “any” element to the particular construct that we want. For example, if we want to send a picture we would create an element with a type of xs:base64Data. You can now attach your picture to this element.

What is a papiNet PIG?

A PapiNet PIG, or Product Identifier Grouping, is one of the most powerful constructs that PapiNet offers for Product or SKU extensibility. Unfortunately, It is not used to its full extent because of concerns about the ease of its interpretation. These concerns are unwarranted.

A Papinet PIG provides the capability for the communication of items not covered by the Papinet standard in a name-value approach.

When you create a ProductIdentifier with a type of “Other” the content of the ProductIdentifier element represents the name of the characteristic being communicated. The content of the ProductDescription element represents the value of the characteristic being communicated. In other words a PIG is a name-value pair.

The confusion, or concern, that people have about a PIG construct is that instead of having a parent element that groups the name-value pairs together a PIG is grouped using a repeatable sequence content model. While this is an unusual construct parsing this type of construct is very easy. What you will do:

1. Select ProductIdentifier nodes that a type of “Other” and content equal to name of the characteristic you want to read.
2. Then read using the “next sibling” capability found in XPath or in the programming language of your choice. The logic I use is to read the next sibling until the name of the node is not equal to ProductDescription. This approach permits the capture of repeatable instances of the value being communicated.

Product Attributes, the papiNet Electronic Catalogue

If customers don’t know what you offer they cannot request it. The papiNet ProductAttributes XML document provides a standard mechanism for the communication of product characteristics and identification. For an Excel plug-in to read and produce a papiNet Product Attributes message navigate to http://www.drybridge.com/products/accelerator/accelerator.htm