Appendix F --o Project Technical Information

GoFiler Legato Script Reference

Legato v 1.5b

Application v 5.24b

Table of Contents	< < Previous	Next >>

Appendix F — Project Technical Information

1.0 Introduction

1.1 Project Format

1.1.1 Overview

GoFiler project information has been designed in an open, easy to use format to allow external applications to read and write data within a project file. This document describes the format and some of the internal data fields.

The GoFiler project is a combination of two separate XML files: Project Information and EDGAR Information. In addition, a header area is provided. Note that because of the combination of the two XML sections, this file violates the XML root structure concept. Certain off-the-shelf XML readers may have to be adjusted to accommodate this structure. While this structure may be inconvenient, it has been designed to accommodate both the project and the various versions of EDGAR XML. If not structured in this manner, a separate project schema would be required for every permutation specified by the US Securities and Exchange Commission (SEC). Further, such schemas would have to be updated and combined with every EDGAR system change.

The project information follows the standard PSG project information which contains project information, entry information and other data for distribution. EDGAR information is dependent upon the particular form being represented. It will collect one of the schemas specified by the SEC for the specific form.

A typical structure is as follows (the ellipse character ... represents repeated or additional information):

<?xml version="1.0" ?>

<!doctype gfp public "~//PSG//DTD PROJECT 3X">

<info>

...

</info>

</entry>

</group>

...

</project>

...

1.1.2 Project Header

The header contains basic information for the project signature and control. It must contain the following components:

<?xml version="1.0" ?>

<!doctype gfp public "~//PSG//DTD PROJECT 3X">

The ‘doctype’ method is used to differentiate the types XML from the EDGAR XML which employs one of a number of schemas.

A suffix is added to various headers for forms 13F and 13H.

<!doctype gfp public "~//PSG//DTD PROJECT 3X F13F">

<!doctype gfp public "~//PSG//DTD PROJECT 3X F13H">

Comments are optional and include the application, file, user and signature and basic meta data when the file is generated by GoFiler. The signature is used to verify the creator of the project and may be omitted from the file. Writers can add XML comments anywhere within the stream.

1.1.3 Compatibility

There are two aspects of compatibility to consider: varying versions of the GoFiler family of products and varying versions of EDGAR. The overall project format has remained the same since the inception of GoFiler. The principal change from 2x to 3x was the SEC moving EDGAR submissions from XFDL to XML. This specification is written for GoFiler 4.x, but the underlying project format will remain 3X until such time as a major data structural modification is required.

Data that is not understood by previous versions of GoFiler are ignored.

1.1.4 Project Area

The Project area contains the main portion of the project data. This consists primarily of two parts: project info and the file list. The project info area is principally an area of named values. Some of the values are predefined and fixed, some are for EDGAR control, collaboration and user data.

The second area is a series of “groups’ which are all similarly structured containing items such as the project file entries.

All data is encoded in groups, entries with names and then data. All data is in PCDATA format (encoded for SGML requiring all ‘&’ ‘<’ ‘>’ and non ASCII character encoded as character entities). The project file only supports Windows 1152 or ANSI text.

1.1.5 EDGAR Area

EDGAR Information matches the EDGARLink Online XML Technical Specification except documents are not encoded within the XML stream. Rather, placeholders are added indicating the position of the documents. For example:

<cor:documents>

<com:document>

<com:conformedName>form8k.txt</com:conformedName>

<com:conformedDocumentType>8-K</com:conformedDocumentType>

<com:description>Form 8-K</com:description>

</com:document>

<com:document>

<com:conformedName>ex-99.txt</com:conformedName>

<com:conformedDocumentType>EX-99</com:conformedDocumentType>

</com:document>

</cor:documents>

The file content would normally be mime encoded:

<com:description>Form 8-K</com:description>

<com:contents>

PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09

...

DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMA0K

DQoNCg0KDQoNCg0K

</com:contents>

It is worth noting that even though GoFiler projects contain EDGAR XML, they are not suitable for submission to the SEC.

When creating a new project file, a third-party writer can loosely add in the EDGAR information. For example:

<cor:edgarSubmission>

<cor:submissionType>S-1</cor:submissionType>

</cor:edgarSubmission>

GoFiler does not perform strict interpretation of the EDGAR namespaces so data can be loosely added. When rewritten by GoFiler, the EDGAR XML will be corrected. Note that due to the complexity of EDGAR XML, representations of certain data in a “loose” manner may not be possible. Software developers creating software for project file generation should carefully test each form.

The EDGAR information is not discussed further in this document. It is suggested that readers reference the SEC materials regarding schema, structure and allowed values.

1.2 Processing Errors

Most structural errors will be displayed in an info view log when a project is open. That log contains coding errors. The project reader has not been rigorously tested for all XML error conditions so authors are cautioned to follow coding standards carefully.

2.0 Overall ‘Info Table’ Format

2.1 Overview of the Info Table

Info area contains a series of named variables or fields (sometimes referred to as meta data). While there are predefined names, users can also embed data in the Info Table, provided that predefined names are avoided.

2.1.1 Structure

<info>

...

</info>

2.1.2 Entry Structure

Name — specifies the name of the item. While names are not required to be unique, GoFiler’s names are always unique.

Data — A PCDATA formatted string not to exceed 4096 bytes.

2.1.3 Custom User Information

Custom information can be embedded and will be carried and managed by the application. Such fields can be used for production information, billing information or any other purpose.

While the number of data fields is unlimited, the size of each field is limited to approximately 4096 bytes.

2.2 Predefined Project Info Data

2.2.1 Overview

A number of keywords are reserved for GoFiler to store project properties, filing information and collaboration data. The format of this information is open and may be freely read and written.

2.2.2 Project Properties

The following named variables specify each predefined project property. These are available from the Project Properties function and can be used for proofing.

Base-Path — A path to reference non-qualified file entries. If blank, all entries are expected to be relative to the project path.

Name — General project name.

Description — General description.

Application — Application name.

Matter — Matter or Job Number.

Client-Name — Client name for the project.

Agent-Name — Agent name for the project (presumably the name of the service, agent, law firm or company.

Revision — Open format revision string.

Comments — Any general comments.

ProjectViewSettings — Information about the view setting (not available in project properties).

While it is an internal matter, these items are held in a different pool area within the application and writers are cautioned not to exceed the maximum of 1024 total characters (with /0).

2.2.3 Embedded Notifications

There are two types of notifications that can be employed with GoFiler: embedded and collaborative. Embedded notifications are part of the project information and can only be added to a project via direct coding intervention; there is no application user interface. The collaborative notifications are discussed in a separate section.

Notification example 1, plain text:

Notification example 2, HTML text:

Example of coding:

<info>

<entry name="NotifyUserProjectOpen">Proofing Notice,Client wants blue stripes.
Make sure to change before proofing.</entry>

<entry name="NotifyUserProjectOpen">"Title","Text".</entry>

</info>

The format is <entry name="type"> data </entry>. The name field determines the type of notification and there are four types of notifications:

NotifyUserProjectOpen — Message appears when the project is opened.

NotifyUserProjectFile — Message appears before performing any type of filing. This is presently implemented only for general EDGAR filings (eg: 10-K, 10-Q, etc., not 13H). Cancel will stop the filing.

NotifyUserProjectFileLive — Message appears before performing any live filing. This is presently implemented only for general EDGAR filings (eg: 10-K, 10-Q, etc., not 13H). Cancel will stop the filing.

NotifyUserProjectProof — Message appears before performing a project proof.

Names can have an optional suffix preceded by a dash for the purposes of production system control. Suffixes are ignored. If more than one of the same type of message is in the list, the messages are presented to the user in order.

The notification data can be in three forms:

Simple Text No Title — Basic text dialog (not shown above as example 1).

CSV in the form Title/Text — First example above.

HTML — Second example shown above as example 2. Must be encoded as PCDATA. For example:

<P STYLE="text-align: center; ">Proofing Notice</P>

2.3 EDGAR Specific Project Information

2.3.1 Overview of EDGAR Control Data

A series of named fields are used to aid in the overall control of the project for EDGARizing, submission collaboration and other data fields. These named fields always start with the prefix “ProjectInfo”.

2.3.2 Project Last Validate

Every time a project is validated, this named variable is updated. If the variable is not present, the project has never been validated.

Name:

ProjectInfoLastValidate

Structure:

Time: time; Fatal: nn; Error: nn; Warning: nn

The time is in ISO-8601 format and is used to determine if any files have been altered subsequent to validation. The nn values specify the overall error count.

2.3.3 Project Submission Information

When a project is submitted or queued for submission, certain meta data is added to the project information table. If actions are taken outside of GoFiler or in a version prior to 4.0a, the project submission information will not be updated.

Project submission information takes the form of a series of named fields that indicate the time and various meta information. There are three main submission items: (i) last submission, (ii) last live submission, and (iii) a history of submissions. The last submission and live submission are provided for easy access as opposed to having to iterate through the submission history.

The format of the submission data is the same for all three fields:

Accession: accession; Date: date; Type: type; User: username

Where:

accession

is the returned accession number after the filing has been completed or may be the word “queued” if the filing was submitted via the Novaworks Submission Service (NSS).

date

contains the local computer’s date and time of the submission (not the SEC time) in ISO-8601 format.

type

will be either the string “live” or “test”.

username

is the Windows username of the user submitting the filing.

ProjectInfoLastSubmission

Name:

ProjectInfoLastSubmission

Structure:

Accession: accession; Date: date; Type: type; User: username

ProjectInfoLiveSubmission

Name:

ProjectInfoLastValidate

Structure:

Time: time; Fatal: nn; Error: nn; Warning: nn

ProjectInfoSubmissionxxxx

Name:

ProjectInfoSubmissionxxxx where xxxx is a four digit serial number.

Structure:

Time: time; Fatal: nn; Error: nn; Warning: nn

ProjectInfoSubmissionCount

Name:

ProjectInfoSubmissionCount

Structure:

This is a control field that is principally used to track how many ProjectInfoSubmission fields are present.

2.4 Locking

2.4.1 Overview

A project can contain one lock with certain properties. Locks essentially prohibit certain functions from being executed until the lock is removed or it expires.

An entry appears under the keyword ‘ProjectInfoLock’.

2.4.2 Lock Format

The lock data is in “parameter: value;” format with predefined keywords for the parameters. If parameters are added which are not known by the application, they are ignored. However, if the lock data is modified, unknown parameters are discarded. Note that the value is encoded in a URL-like style where the protected characters ‘:’, ‘;’ and ‘%’ must be encoded. If a URL encoder is used, all URL encoding styles are employed while reading fields, only protect codes are encoded during writing.

Examples of records (note the ‘...’ indicates omitted data and line returns have been added for clarity):

<info>

<entry name="ProjectInfoLock">HardLock: 1; Action: EDGAR_PROJECT_OPEN;

Until: 2016-04-25T21%3A30%3A00Z; LockedBy: john.scully;
LockOn: 2016-04-18T14%3A40%3A00Z; Color: Yellow;

Notes: This project has been cancelled.</entry>

...

</info>

Parameter fields names:

HardLock — Any text in this field indicates a hard lock (the application will write ‘1’). A hard lock prevents a project from opening. (When open the project is opened in the application it is displayed to allow viewing with a message box indicating the project is locked. After the user presses OK, the project is closed.)

Action — One or more menu functions codes blocked by the locking action. The total size of this field is limited to 128 characters and values are separated by spaces.

Until — If an expiration date has been set, specifies the date and time the lock will be lifted in ISO-8601 as UTC.

LockedBy — User name or ID performing the lock. This is normally set to the user’s login ID when a lock is set using the lock menu function. Field is limited to 64 characters.

LockedOn — Date and time the lock was put in place in ISO-8601 as UTC.

Notes — General text describing the lock. A field up to 256 characters.

Authority — Required authority to unlock. A field up to 64 characters. Note that this is not a password and is stored as clear text within the project (therefore a password that might be used somewhere else, like a user’s password, should never be used). It is meant to provide an extra level of control and to help enforce filing protocols and policies — particularly in an environment where multiple users will be interacting with the project. If an encrypted password strength enforcement policy is required, users are urged to the User Account Control feature which is not part of the project file.

Color — If specified, a CSS-style color specification which is used for displaying the background color for the lock notification dialog. Web names, ‘#rrggbb’ hex format and ‘rgb(r,g,b)’ can be used. Invalid colors will be ignored by the lock display function.

2.4.3 Hard Locks

A hard lock can only be removed by manually editing the project file or if the lock time expires if a date and time was set.

2.4.4 Lock Dialog Example

2.5 Collaboration Data

2.5.1 Overview

Certain collaboration data can be stored in the information area of a project and within file entries. Base data is stored in name pairs either as entries in the case of the Project Information Table or as values in the case of a project file entry.

See the Collaboration Technical Information document for information on the structure of records that may be inserted into a project.

2.5.2 Named Types in the Info Table

All collaboration data fields in the information section will have the following prefixes:

ProjectInfoAlert — A notification record.

ProjectInfoEvent — A calendar event. Reserved for future use.

ProjectInfoNote — A note. Reserved for future use.

ProjectInfoTask — A task.

Examples of records (note the ‘...’ indicates omitted data and line returns have been added for clarity):

<info>

...

<entry name="ProjectInfoTask0002">PT00002@2014-02-10T13:33:55: "v1.0",

"Exhibit 32.1","Complete","None","High","None","","Scott A. Adams",

"David Smith","",

"Review this with the new CFO prior to making new document.",

"2014-02-10T12:32:00","","","","","","","sa_theis@hotmail.com",""</entry> <entry name="ProjectInfoTask0001">PT00001@2014-02-10T14:27:10: "v1.0",

"Complete Certification Ex 31.1","Complete","None","Medium",

"Data Collection","","Scott Adams","Rick Anderson","",

"Collect Data for Sarbanes–Oxley.",

"2014-02-10T12:30:00","","2014-02-10T09:00:00","","",

"Pick up last year","","sa_theis@hotmail.com",""</entry>

</info>

3.0 Project File Entries

3.1 File Entries

3.1.1 Overview

A project will have an associated file list. The group contains an entry for each file and may also contain non-file or virtual entries. When creating a project, the creating software need only add the filename. Other information can be added or modified later. When the project is saved, certain fields will always be added.

3.1.2 Structure

<value name="Description">QTR. REPORT</value>

</entry>

. . .

. . .

</group>

3.1.3 Entry

Each entry is started with <entry> tag and closed with the </entry> tag. It must contain one name group; all other fields are optional. While certain fields, such as the EDGAR ‘Document-Type’ are required for filing, they are not required to create a project.

The <entry> tag pos parameter specifies the zero-based index of the file entry in the Project Database. The value is ignored on project load and written on project save. It can be used by readers to identify the file position relative to other files. When a project is written, the files are always written in entry order without regard to the display order within the project view.

3.1.4 Entry Structure

The entry structure is as follows:

Name — specifies the entry file name of the item. The filename can have an absolute path or be relative to the project path. The name can also contain non-file entry information and designated by a keyword surrounded by double colons (‘::’). For example:

<name>::title::01 - Introduction</name>

The value trailing the ‘::title::’ will display as a separator in the project file list.

Value — A PCDATA formatted string not to exceed 4096 bytes. These appear containing information pertaining to the entry.

Each entry will have one or more value strings. Reserved value names are as follows:

Modified — The modified time of the file in ISO-8601 format and UTC. This can be used to aid the application in determining whether a file has been updated.

Size — The size of the file.

Type — Specifies the type of file either in hexadecimal or as a file type code. If unknown or 0x00000000, the file type is retested when the project is opened.

Flags — A series of bitwise values in hexadecimal indicating the status and condition of the file and entry. The bits are as follows:

Definition (Internal/Legato)		Bitwise	Description
Error
	PE_ERROR_MASK	0x000000FF	File Error Mask, Standard Win32 SDK Code
	PE_FILE_ERROR	0x00000100	File for Entry is in Error
File Information
	PE_FILE_READ_ONLY	0x00000200	File is Read-Only
	PE_EXPANDED	0x00010000	Expanded Item‡
	PE_DIRTY	0x00020000	File Data is Out of Date
Type of File
	PE_MASTER_FILE	0x00040000	File is Master Multiple Components‡
	PE_COMPONENT_FILE	0x00080000	File is a Component‡
	PE_EXTERNAL_FILE	0x00100000	File is External to Project
	PE_VIRTUAL_FILE	0x00200000	File is Virtual (no actual file)
Entry (Non-File)
	PE_PLACEHOLDER_ENTRY_MASK	0x0F000000	Placeholder Entry (Display Only)
	PE_PLACEHOLDER_NONE	0x00000000	Not a Placeholder
	PE_PLACEHOLDER_TITLE	0x01000000	Display Title
Combination Flags
	PE_NOT_REAL_FILE	0x0F200000	Not a Real File
‡ Reserved for future use.

Document-Type — Document type value. The value started can be larger than allowed for EDGAR. The creator must limit the size of the value.

Description — Document description value. The value started can be larger than allowed for EDGAR. The creator must limit the size of the value.

Member-Flags — Publishing membership flags. For EDGAR, the absence of a value also counts as an EDGAR entry. The bitwise flags are as follows:

Definition (Internal/Legato)	Bitwise	Definition
PE_MEMBER_WEB	0x00000001	Member of Web
PE_MEMBER_BOOK	0x00000002	Member of of Book Publication
PE_MEMBER_HELP	0x00000004	Member of Help System
PE_MEMBER_EDGAR	0x00000008	Member of EDGAR Filing
PE_MEMBER_SUPPORT	0x00000010	Member of Support
PE_MEMBER_USER_A	0x00000020	Member of User A
PE_MEMBER_USER_B	0x00000040	Member of User B

Edit-Status — General document or entry edit status. The value is not used for EDGAR except certain forms and for Modules and Segments where the value is the CIK. It is also used for confidential marking on certain forms.

Comment — Document or entry comments. The value is not used for EDGAR except certain forms and for Modules and Segments where the value is the CCC.

Switches — Publishing or other switches.

Upload-Size — Size of file on the last server upload. Not used for EDGAR.

Upload-Modified — Modified date and time of the file when uploaded in ISO-8601 of the last server upload. Not used for EDGAR.

Upload-Time — Date and time in ISO-8601 of the last server upload. Not used for EDGAR.

Parent-Index — Used as link to other entries. Keyword is reserved but not presently used.

Dependency-Link — Used as link to dependency table. Keyword is reserved but not presently used.

Value pairs can also be user-defined or related to collaboration. If used for collaboration, the value will have the prefix ‘Project’. Users should avoid that prefix.

User values are held by the Project Database and passed through on load and save. They can also be accessed from Legato functions.

3.2 Dependency-List

3.2.1 Overview

Reserved for future software versions.

3.3 Distribution-List

3.3.1 Overview

Reserved for future software versions.

3.4 Server-List

3.4.1 Overview

Reserved for future software versions.

3.5 Preferences

3.5.1 Overview

The project file may contain group-level specified information for local software preferences. Projects can override certain application-level preferences. Each module/section of the application’s INI parameters are stored in XML entry format.

3.5.2 Structure

<value name="CIK">r/tRwdxJzRZs9k/8niUkMQ==</value>

<value name="CCC">qPNdd5QVg/ElqJ+2di9kMQ==</value>

<value name="Password">qfkRgaQVhPRl5J2wOwVkYQ==</value>

</entry>

</group>

3.5.3 Entry

Each entry is the equivalent of an INI section name. The section data is then presented as a series of <value> tags.

Name — Specifies the value name; this is the equivalent of the key name within the INI value.

Value — A PCDATA formatted string not to exceed 4096 bytes.

Table of Contents	< < Previous	Next >>

© 2012-2024 Novaworks, LLC. All rights reserved worldwide. Unauthorized use, duplication or transmission prohibited by law. Portions of the software are protected by US Patents 10,095,672, 10,706,221 and 11,210,456. GoFiler™ and Legato™ are trademarks of Novaworks, LLC. EDGAR® is a federally registered trademark of the U.S. Securities and Exchange Commission. Novaworks is not affiliated with or approved by the U.S. Securities and Exchange Commission. All other trademarks are property of their respective owners. Use of the features specified in this language are subject to terms, conditions and limitations of the Software License Agreement.