Electronic Representation of Phytosanitary Certificates

Shared by: LeePenny
-
Stats
views:
6
posted:
6/23/2009
language:
English
pages:
31
Document Sample
scope of work template
							           Jason Dittrich
          NAPPO E-CERT
Technical Advisory Group
Facsimile / Digitized Image

EDI – Electronic Data Interchange

XML – Extensible Markup Language
Pros
◦ Simple implementation using readily available
  technology
◦ Human-readable with no processing necessary
Cons
◦ Data in document not easily extracted
◦ Computer validation of contents virtually impossible
Pros
◦ Compact format for low bandwidth transmission
◦ Proven technology in wide use in many industries
◦ Content restriction through document definition
  available
◦ Machine validation built in
◦ Simple data extraction
Cons
◦ Not human-readable. Must be processed before
  viewing easily
◦ Machine processing tools are mainly proprietary
  and can be costly
◦ Beginning to be perceived by many as legacy 20th
  Century Technology
Pros
◦ International Standard developed by the W3C (World
  Wide Web Consortium)
◦ Human-readable. Machine processing not strictly
  necessary
◦ Content restriction through document definition
  available (XML Schema)
◦ Machine validation possible
◦ Tools for reading/writing XML widely available and
  low cost
Cons
◦ Larger data size due to self-describing format
  requires either:
   Data compression
   High bandwidth connectivity
UN/CEFACT Recommends using XML for new
projects that do not have legacy systems to
consider
NAPPO E-Cert Panel recommends using XML
for representing certificates
    The following section(s) assume the
international community decides upon using
  XML as the standard format for electronic
 representation of phytosanitary certificates.
The XML Schema standard developed by the
W3C is currently the de facto standard for
defining document contents

XML Schema provides means for describing,
with varying degrees of specificity, what a
document can and should contain
Listing of data elements included in a
particular type of document
Documentation of data elements
Type of information each data element can
contain
Type of data: Lists (enumerations)
Required data elements
Few restrictions imposed by schema
Generic definition allows for use with more
than one type of certificate, e.g. Phytosanitary
certificates, live animal certificates, meat
certificates, etc
Business rules must be imposed outside of
schema, either:
◦ Internally for each participating NPPO
◦ Centrally using common validation system
UN/CEFACT SPS_Certificate Schema already
published:

  http://www.unece.org/uncefact/data/
     standard/SPSCertificate_1p0.xsd
Schema definition more restrictive than
generalized definition

Business rules imposed within schema itself

No reuse for other certificate types: schema
specific to phytosanitary certificates
What approach does the international
community want to use for electronically
representing phytosanitary certificates?

◦   Digitized Image / Facsimile
◦   EDI
◦   XML
◦   Other
If XML is selected by the community as the
method to use, which approach to XML
Schema use should be used?


 Generalized or Detailed Schema
           Definition?
For the Generalized Schema Definition,
business rules are not imposed within the
schema itself and must be implemented
separately. Where to validate business rules?

◦ Method 1: Each NPPO builds business rule
  validation into their internal systems

◦ Method 2: International Community creates a
  central system for validating business rules
For the Detailed Schema Definition, business
rules are imposed within the schema itself.
There is no existing standard phyto-specific
schema, so what vehicle should be used for
building it?

◦ UN/CEFACT

◦ IPPC

◦ Other organization?
To implement electronic certificates, the
international community must decide:

◦ How to best represent phytosanitary certificates
  electronically?

◦ How does the community want to use the information
  sent?

◦ Should business rules be imposed as part of an
  international standard?
   If yes, should this be done as part of the schema or
   separately either within each country or centrally.

						
Related docs