GB/T 36147.2-2018Security management systems for the supply chain -- Electronic port clearance (EPC) -- Part 2: Core data elements (English PDF)

1.1 Overview

This part of GB/T 36147 specifies the general requirements for safety and security information requirements for electronic port clearance, and improved XSD data.

Type, general data type, core data type, electronic representation.

This section applies to the definition and use of core data elements between ships and ports for safety, security and offshore operations. It can also be used for ships.

Information exchange between ships and ship agents, port and ship operators or ship managers.

1.2 Application of core data elements

This section includes definitions of core data elements for Electronic Port Clearance (EPC). These data elements include ship-to-shore and shore pairs as defined below

All requirements of the ship.

a) all FAL Standard Announcements (FAL1~FAL7) as defined in the Convention on International Facilitation of Sea Transport (FAL Convention);

b) ISPS reporting requirements as defined in ISPS and MSC1305;

c) regular ship reporting requirements as defined in IMOA.851 resolution;

d) Ship-generated waste report as defined in MEPC644 (mandatory in the European Union, see EU/2000/59);

e) the necessary report as defined in the IMOA.862 Resolution on the Solid Bulk Cargo Safety Operational Rules (BLU);

f) ETA report to the pilot station as defined in IMOA.960 Resolution.

Appendix L gives a horizontal comparison between the above requirements and the core data elements.

This section does not include matters such as customs clearance for import and export goods or transportation services provided by the owner.

1.3 Data element types defined in this section

The partial metatypes defined and referenced in this section are shown in Figure 1. The gray box is an object that is not defined in this section, but the base of this section is used.

This information and results.

The top gray box represents some of the data types in XML Schema Part 2 (XSD-2). The bottommost gray box represents the inclusion

Use the electronic XML message for the data element defined in this section.

Figure 1 Data elements in this section

All the elements in each group are not included in Fig. 1, except that part of the elements are selected in each group as an example. The definition of the meta from top to bottom is as follows.

---Improve the XSD type. These are the limitations imposed on this element by the basic elements.

---General data types. These data types represent common concepts, such as port representations or certificates, which need to be specified rather than based on

Defined below;

---Core data types. These data types are defined by context rather than common concepts, such as using Hong Kong instead of ordinary ports, or using newspapers

The location is replaced by the general location.

When the message is defined (as shown by the arrow in Figure 1), this section does not prohibit the use of data types other than the EPC core data element. However, this

These data elements should be given a specific meaning in the message format specification.

1.4 Data element representation structure

The structural outline of this section is shown in Figure 2. The upper two rectangular boxes represent the general data types specified in the previous clause, while the bottom rectangle

The columns in the box represent the EPC core data elements.

Figure 2 Schematic diagram of this part

The order of grouping is based on the order in which it appears in a typical FAL form.

a) Ship ID. Ship identity information and contact details;

b) goods. data relating to the type of goods and goods;

c) Crew and passengers. data relating to crew and passengers;

d) class and certificate. class and certificate related data;

e) Security. mainly related to ISPS data;

f) Service related. data relating to the services required by the ship, including message headers and customs clearance requirements and status;

g) Ship elements. static data of the ship;

h) ship operations. data relating to operations or navigation, including physical data of changes, such as draughts that vary with loading;

i) Waste and the environment. Currently, this article includes waste information.

The core meta-grouping is for convenience only and does not affect the structure of the EPC message. In addition, the data elements defined in the XSD file will not

With any formal grouping, all data elements have the same namespace.

3.1 Terms and definitions

The following terms and definitions apply to this document.

3.1.1

Character character

The minimum unit of text specified in ISO /IEC 10646.2003.

Note. Legal characters include. labels, carriage returns, line feeds, and legal characters in the Unicode Standard and ISO /IEC 10646. The version referenced in this section is

Previously released for use; new characters may be added to modified or future versions of the Unicode Standard and ISO /IEC 10646.

3.1.2

Core data element coredataelement

See Chapter 7 definitions in this section.

Note. The core data element represents the content between the XML start and end tags. The tag has the same name as the core data type, except that the tail string is omitted.

"Type".

3.1.3

Core data type coredatatype

The data types specified in Chapter 7 of this section.

Note. The tail string "Type" is included in all core data type names, and the trailing character is canceled when the data type is used as the core data element.

3.1.4

Data type datatype

The core data type (3.1.3) or other data types specified in Chapter 5 or Chapter 6 of this part.

Note. All data types end with "Type".

3.1.5

Electronic port clearance electronicportclearance; EPC

The port authority and the user exchange electronic messages through a single window to achieve customs clearance at the port.

3.1.6

Voyage leg

A non-stop voyage between Hong Kong and Hong Kong.

3.1.7

Oil, bulk, ore (transport) ship OBO; oil-bulk-orecarrier; O/Ocarrier

Designed to be similar to conventional bulk carriers but equipped with piping, pumps and inert gas units to facilitate loading of oil in designated compartments.

3.1.8

Route voyage

The ship sails from the port of origin to the port of destination with or without intermediate stops.

Note 1. The route is determined by the ship operator or the shipowner.

Note 2. See the voyage (3.1.6).

3.1.9

XML schema XMLschema

The structure definition of an XML file, see XML Schema Language (XSD).

Note. The XML schema language itself is a valid XML structure.

3.2 Abbreviations

The following abbreviations apply to this document.

BLU. Bulk carrier loading and unloading 1) (BulkLoading and Unloading)

DG. Dangerous Goods 2) (DangerousGoods)

HS. World Customs Organization's Harmonized System (World Customs Organization's Harmonized System)

FAL. International Maritime Organization Facilitation Committee and Standard Form as defined in the FAL Convention (Facilitation, IMO's

FacilitationCommitteeandstandardformsdefinedintheFALConvention)

IRI. International Resource Identifier [19] (InternationalizedResourceIdentifier)

ISM. International Safety Management 3) (International Safety Management)

ISPS. International Ship and Port Facility Security Code 4) (InternationalShipandPortfacilitySecurity)

RORO. Ro-Ro ship (Rol-on/Rol-off (ship)]

TDED. Trade Data Element Directory [2] (TradeDataElementsDictionary)

URI. Uniform Resource Identifier

URL. Uniform Resource Locator (UniformResourceLocator)

XML. Extensible Markup Language (ExtensibleMarkupLanguage)

XSD. XML Schema Definition Language (XMLSchemaDefinitionLanguage)

1) The BLU rules can be found in the appendix to the IMOA.862 Resolution.

2) Sometimes "hazardous and toxic substances" are used instead of "dangerous goods".

3) The definition of the ISM Code can be found in Chapter IX of Reference [6].

4) ISPS rules are defined in Ref. [6] Chapter XI-2.

4.1 Use of the XML namespace

4.1.1 XSD Namespace

All data elements defined in references [16], [17] and used in this section use the same namespace "xs". Therefore, the number

The type name prefix is "xs". The XSD definition file header includes the following features.

\u003cxs.schema..

4.1.2 ISO 28005-1 namespace

The data types defined in this section are defined in the namespace "epc". Therefore, the data type name prefix is "epc.". XSD

The header of the file includes the following features.

\u003cxs.schema..

4.2 Principles for Creating Tag Names in Message Files

The data types defined in this section can be used to create XML messages to facilitate the exchange of information between ships and ports. In the XML file

The information element should have a tag name derived from the core data type defined in this section. The rules are as follows.

a) If the information element in the XML file is related to the core data type defined in this section, the tag name and core of the information element

The data type is the same without the suffix "Type" or "ContentType" of the core data type;

b) If a new information element is created, its name and type shall reflect the principles given in this section.

4.3 Structure of data type definition

4.3.1 Name

All data types defined in this section should have a name that should be included in the front of the header of the definition data type.

The data type name should conform to the XML tag naming convention [15] with the following additional restrictions.

a) Names end with the string "Type".

b) The suffix of the enumerated data type is "ContentType".

Note 1. Some core data elements also end with "Type". In this case, the suffix of the corresponding core data type is "TypeType".

c) This section uses "big camel spelling" in all core data types, for example when the tag name consists of a series of conjunctions.

Each word should begin with an uppercase letter;

d) The name consists of characters in the set (A~Z), (a~z), and (0~9).

Note 2. The content of communication between ships and ports in port customs clearance is easy to understand. The name uses common British English without any special characters.

The name is usually in singular format. When the data element includes a list of items, the label name is in plural format.

4.3.2 Definition

Each data type is defined, and in the definition, the content that the data element should include and the clear table in which the case is valid are given.

Said. This is the first paragraph after the chapter head.

4.3.3 Type

Each data type is defined as a segment of the XSD code. This section covers the actual data type definition but is not a valid XML text.

Pieces. Appendix M gives an overview of the syntax elements used. For the description of the definitions, users of this section should refer to reference [16].

4.3.4 Expression

For the normalization of data fields, see the paragraph. For example, this paragraph will give a normative reference to the official source code of the enumeration.

4.4 Principles for defining enumerated types

An enumerated type, for example, a type associated with a fixed set of code values, is defined in one of three ways.

a) When the code set is small and undefined and maintained by an authority other than this part, the allowable code value is the same as the XSD limit

Listed in the data type definition.

b) If the code set is large and not defined by an external authority, the code set is in the normative appendix. Defined in a single XML file in 8.2

How many code sets can be embedded.

c) When the code set is maintained by an external authority, define the data type as a tag and as a discovery code set and how the code set is

The reference used in the core data element. Some of the most commonly used codes are usually included in the informative appendix. 8.2 can be used to compile XML

The value in .

Note. It is not possible to verify the use of code defined in items b) and c) above using XSD mode.

4.5 Character Sets for Data Fields

This section allows all character sets supported by XML (see 8.1). The expression in the data type definition section may impose additional restrictions.

4.6 Unused XML attributes

The data types defined in this section do not use XML attributes. All information is included in the XML start and cutoff tags.

4.7 empty label

Mandatory labels (unmarked minOccurs="0") should normally contain valid data. Optional tags are usually not counted in the message, it may be

Empty, such as no end tag, or the tag content is empty. The recipient of the message should handle all empty tags in the same way.

4.8 minOccurs and maxOccurs default values

According to reference [16], the default value of minOccurs and maxOccurs is 1. In order to define the chapter in the data type in this section

Medium shortened type regulations.

5.1 Overview

The definition of the improved XSD data type used in this section can be found in Ref. [17]. 5.2~5.10 contains the use of this part of the application

Additional restrictions on these data types.

5.2 epc. anyURI---generic URI

definition.

This data type includes a valid universal URI. It may be an email address prefixed with "mailto." or an external file with the prefix

"file.".

Types of.

\u003cxs.simpleTypename=\"anyURI\"\u003e

\u003cxs.restrictionbase=\"xs.anyURI\"/\u003e

\u003c/xs.simpleType\u003e

Expression.

All common URIs allowed by reference [17] (possibly compiled to IRI) are also allowed in this section. However, to ensure compatibility with older systems,

It is recommended that users use URL-type strings (seven-character sets) until the IRI concept is fully implemented.

5.3 epc.Boolean---Boolean variable

definition.

Data types include data variables with logical values that are true or false.

Types of.

\u003cxs.simpleTypename=\"boolean\"\u003e

\u003cxs.restrictionbase=\"xs.boolean\"/\u003e

\u003c/xs.simpleType\u003e

Expression.

All variable values allowed by the XSD definition given in Ref. [17] are permissible. When the value in the Boolean type is used to represent the pair

When the answer to the yes/no question is true, it means "yes" and false means "no".

5.4 epc.date---regular date

definition.

Data types include dates, except for additional time or time zone information.

Types of.

\u003cxs.simpleTypename=\"date\"\u003e

\u003cxs.restrictionbase=\"xs.date\"/\u003e

\u003c/xs.simpleType\u003e

Expression.

Is the date in the standard XSD format, without any time zone encoding.

The sender of the date information should not include time zone information. The recipient should be prepared to receive the time zone code, but will be in subsequent data processing.

ignore.

5.5 epc.dateTime---Time and date with time zone

definition.

This data type includes the date, including time and time zone information.

Types of.

\u003cxs.simpleTypename=\"dateTime\"\u003e

\u003cxs.restrictionbase=\"xs.dateTime\"/\u003e

\u003c/xs.simpleType\u003e

Expression.

Is the date and time in the standard XSD format, including time zone encoding.

The sender of the date and time information should include time zone information. The recipient should be prepared to receive the no time zone code. In this case, time zone

Undefined, the system should take appropriate action to process the data.

Note 1. The time zone value "Z" is a valid code referring to GMT or UTC time.

Note 2. The second zone can include a value of 60 (when a leap second occurs).

5.6 epc.decimal---carrying system

definition.

This data type is used to specify the accuracy.

Types of.

\u003cxs.simpleTypename=\"decimal\"\u003e

\u003cxs.restrictionbase=\"xs.decimal\"/\u003e

\u003c/xs.simpleType\u003e

Expression.

The carry type represents a subset of real numbers and is generally represented by a carry system. The value of the space fraction is obtained by multiplying the integer by the negative power of 10.

The set of numbers, for example i x 10^-n, where i and n are both integers and n >= 0. Accuracy is not reflected in the value space; numbers 2.0 and 2.00

There is no significant difference. The order relationship of the carry system is consistent with the real number and is limited to this subset.

The carry system has a finite length sequence of decimal places separated by decimal points (

\u003c/xs.simpleType\u003e

Expression.

This type specifies the time period according to reference [17]. The common format is "[-]PnYnMnDTnHnMn.