Please note: V3.0 of the specification is acceptable until 30 June 2018. This version (V3.1) becomes effective on 1 January 2018.
On this page: Backbone file for AU Module 1 | XML root element | Envelope | Heading elements | Node extensions and leaf elements | Lifecycle operations | Files and folders
Backbone file for AU Module 1
The Australian Module 1 eCTD backbone file is comprised of:
- a fixed eXtensible Markup Language (XML) root element
- the envelope elements
- the eCTD heading elements describing the files provided.
Creating the Module 1 eCTD backbone file
To create the Australian Module 1 backbone file for a given sequence:
- Create an XML file containing the standard XML root element with the appropriate XML declaration using authenticated eCTD preparation software.
- Create an envelope with elements containing the appropriate metadata values describing this sequence.
- Create elements as needed for this sequence:
- Heading elements, organizing the Module 1 content to meet our review requirements
- Leaf elements, providing a file system reference to each file being submitted along with other information such as eCTD check-sum and life-cycle information.
- Name the Australian Module 1 eCTD backbone file au-regional.xml and place it in the au subfolder within Module 1, i.e. within the m1 subfolder of the sequence.
- Validate the resulting backbone using a suitable eCTD validation tool.
Style-sheets
The AU Module 1 is provided with a standard style-sheet that:
- can be used to view content
- displays the complete Module 1 table of contents, i.e. all sections, irrespective of whether files are present in those sections
- enables you to use a browser to open the content in Module 1
- is not part of the specification package.
You can submit eCTD applications with or without the style-sheet.
We will not use the style sheet to review content.
The style-sheet is not checked during the validation process.
XML root element
All Australian Module 1 backbone files will contain the standard XML root element.
The required text includes an XML declaration and the root element tga_ectd with its attributes linking this XML file to the XML definition.
The line breaks inside of the tga_ectd element as shown in the following two excerpts are not mandatory.
Excerpt 1 - XML root element without style-sheet
The following code shows the root section of the backbone file without a style sheet reference and is the standard for the root section:
<?xml version="1.0" encoding="UTF-8"?><tga_ectd schema-version="3.1" xmlns="tga_ectd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="tga_ectd ../../util/dtd/au-regional.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" >
Excerpt 2 - XML root element with style-sheet
If you use the au-regional.xsl style sheet it must be referenced as follows:
<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="../../util/style/au-regional.xsl" type="text/xsl"?><tga_ectd schema-version="3.1" xmlns="tga_ectd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="tga_ectd ../../util/dtd/au-regional.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" >
Envelope
The XML envelope is a key part of the eCTD specification. It is reproduced in Table 4 below.
XML Element | Description | Constraint | Occurrence | Defined List |
---|---|---|---|---|
esub-id | e-Identifier | Mandatory | Single | |
client-id | eBS Client ID | Mandatory | Single | |
aan | Approved Name(s) | Mandatory | Multiple | |
product-name | Trade Name(s) | Mandatory | Multiple | |
artg-number | ARTG Number(s) | Optional | Multiple | |
submission-number | Submission or Application Number(s) | Mandatory | Multiple | |
sequence-number | Sequence Number | Mandatory | Single | |
related-sequence-number | Related Sequence Number | Mandatory | Single | |
reg-activity-lead | Regulatory Activity Lead | Mandatory | Single | Yes |
sequence-type | Sequence Type | Mandatory | Multiple* | Yes |
sequence-type/sequence-description | Sequence Description | Mandatory | Single | Yes |
submission-mode | Submissions mode | Mandatory | Single | Yes** |
work-sharing | Optional | Multiple | ||
work-sharing/esub-id | Work sharing e-Identifier | Mandatory | Single | |
work-sharing/submission-number | Work sharing submission number | Mandatory | Multiple | |
work-sharing/sequence-number | Work sharing sequence number | Mandatory | Single | |
Contact Email | Mandatory | Multiple |
* The sequence type should only be multiple if the sequence mode is set to work grouping. In all other cases, it should be single.
** The list of values is defined in the schema file and these are: single, work-grouping, work-sharing.
In this section: Submitting multiple values | The defined lists | e-Identifier | eBS Client ID | Approved name(s) | Trade name(s) | ARTG number | Submission number(s) | Sequence number | Related sequence number | Regulatory activity lead | Sequence type | Sequence description | Submission mode | Contact email
Submitting multiple values
You need to provide a separate element for each entry when submitting multiple values for envelope elements such as AAN, Product Name and ARTG Number.
Use the following code as an example for the multiple values in the envelope:
<au-envelope> <esub-id>e061061</esub-id> <client-id>Pharma Inc.</client-id> <aan>Approved Name 1</aan> <aan>Approved Name 2</aan> <product-name>Product A</product-name> <product-name>Product B</product-name> <product-name>Product C</product-name> <product-name>Product D</product-name> <artg-number>123456</artg-number> <artg-number>654321</artg-number> <submission-number>PM-2017-12345-1-5</submission-number> <submission-number>PV</submission-number> <sequence-number>0000</sequence-number> <related-sequence-number>0000</related-sequence-number> <reg-activity-lead code-version="4.0" code="reg-act-lead-6" /> <sequence-type code-version="4.0" code="seq-type-6" /> <sequence-description code-version="4.0" code="seq-desc-2" /> <sequence-type> <submission-mode code-version="4.0" code="seq-desc-1" /> <email>contact1@pharma-inc.com</email> <email>contact2@pharma-inc.com</email></au-envelope>
The defined lists
The defined lists are separate XML files maintained by the TGA containing a standard set of codes for the corresponding envelope element.
These code definition files contain:
- a version number
- a version date
- coded values
- plain texts for each value. Only this value is shown to our evaluators in the review system.
Each coded value:
- has its own assigned version valid-from-version, which defines the first version of the file where this code is valid.
- may also have version information assigned, valid-to-version, which defines an expiration for this code in terms of version number.
<item code="seq-desc-6" valid-from-version="0.8" valid-to-version="0.9">Response to Request</item>
The XML file specifies:
- a number for each version
- a valid-from for each version
- an expired date (if applicable).
<versions> <version number="0.8" valid-from="2014-01-01" expired="2014-04-30"/> <version number="0.9" valid-from="2014-05-01" expired="2015-12-31"/> <version number="4.0" valid-from="2015-06-01"/></versions>
Provide the code attribute value from the appropriate element in the code definition file. Provide the version of the XML file as the code-version attribute value in the appropriate element in the au-regional.xml file. See the example XML code under Submitting multiple values.
We will validate sequences to ensure that codes are valid according to the version information.
e-Identifier
Enter this identifier as assigned in the envelope and use it as the name for the eCTD application folder which contains sequence folders.
Example: e123456
eBS Client ID
The applicant's eBS client ID as used in the eBS client database.
Example: 181
Approved name(s)
The approved name(s) of the ingredient(s) - AAN, ABN, etc. as applicable - as they appear in the Australian Approved Names list.
Example: 100604 amoxicillin.
Trade name(s)
The name or proposed medicine (trade) name to be used on the Certificate of Registration.
Example: incrediPill.
For Master Files, insert name of manufacturing site.
ARTG number
ARTG numbers should be supplied when known, typically for variations to an already registered good. This can be a four-, five- or six-digit number.
Example: 123456
Submission number(s)
The submission number(s) or application number(s) applicable to the sequence being submitted. These should be provided as follows:
- PM-2017-12345-1-5 Prescription medicines submission numbers: Prefix PM followed by the submission number and stream. If the submission number is not yet known it is appropriate to only include the prefix and the stream i.e., PM-1. NOTE that this will apply whether the activity refers to a biological medicine or other molecular type ('chemical' medicine).
- BA-2017-12345-1 Biologicals submission numbers: Prefix BA followed by the submission number. If the submission number is not yet known it is appropriate to only include the prefix e.g. BA.
- OM-2017-12345-1 OTC medicines submission numbers: Prefix OM followed by the submission number. If the submission number is not yet known it is appropriate to only include the prefix e.g. OM.
- Complementary Medicines: For registered complementary medicines the same protocol applies as for OTC medicines as detailed above. For listed complementary medicines no validation is planned at this time.
- PV Pharmacovigilance: No submission number is assigned; PV should be entered for all sequences where pharmacovigilance information is submitted.
- MF Master Files: No submission number is assigned; MF should be entered for all sequences where master file information is submitted.
- MD Medical Devices: Depending on whether the eCTD application is a device application or a conformity assessment, the prefix should be DA or DC e.g. DA-2017-12345-1.
Allowable combinations of the above are:
- PM with PV or MF;
- BA with PV or MF;
- OM with PV;
- PV with PM, BA, or OM;
- MF with PM or BA.
Sequence number
Four-digit sequence number matching the sequence folder being submitted.
Example - 0002
Note that we would not expect the sequence number 0000 to be used unless submitting a baseline sequence. The initial sequence of a regulatory activity should always be 0001.
Related sequence number
The related sequence number is used to group sequences.
This enables us to easily evaluate sequences associated with a particular regulatory activity.
All sequences that belong to a specific regulatory activity should contain the same four-digit number in the related sequence number field as demonstrated in the table:
Sequence | Related Sequence | Sequence Type | Sequence Description |
---|---|---|---|
0001 | 0001 | New Chemical Entity | Initial |
0002 | 0001 | Supplementary Information | Response to Request for Information |
0003 | 0001 | Supplementary Information | Response to Request for Information |
0004 | 0004 | F - Major Variation - New Dosage Form | Initial |
0005 | 0005 | Self-Assessment Review (SAR) | Initial |
0006 | 0006 | G - Minor Variation, New Register Entry - New Container Type | Initial |
0007 | 0004 | Supplementary Information | Response to Request for Information |
0008 | 0004 | Supplementary Information | Response to Request for Information |
0009 | 0004 | Supplementary Information | Product Information |
0010 | 0006 | Supplementary Information | Product Information |
Each Initial sequence of a regulatory activity will reference itself.
Each Supplementary Information thereafter will reference the initial sequence of the regulatory activity.
The related sequence number should be approached similar to the Submission ID described in the US regional specification 2.3.
Regulatory activity lead
The regulatory activity lead identifies the group within the TGA which is expected to take the lead in the review process.
Example: OTC
This example shows how to specify the regulatory activity lead for an OTC medicine. The code for "OTC" is reg-act-lead-4 as specified in the defined list which is identified in 'related information and guidance' below.
<reg-activity-lead code-version="4.0" code=reg-act-lead-4" />
The code version must be specified as an attribute code-version of the regulatory activity lead element.
The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).
Related information and guidance
Reg-activity-lead - Official defined list for Regulatory Activity Lead
Sequence type
The sequence type identifies the type of activity that is being submitted, either:
- the regulatory activity type (for the first sequence of the regulatory activity)
- the supplementary information for the follow-up sequences of a regulatory activity that has already commenced.
Example: Sequence type
This example shows how to specify the regulatory activity lead for a new chemical entity. The code for "New chemical entities" is seq-type-1 as specified in the defined list (see URL given above):
<sequence-type code-version="4.0" code="seq-type-1" />
The code version must be specified as an attribute code-version of the sequence-type element. The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).
Related information and guidance
- sequence-type - Official defined list for Sequence Type
- Sequence Matrix - A summary of which sequence descriptions can be used in combination with which sequence types.
Sequence description
Content description for the submitted sequence should be one of the values from sequence-description.
Refer to the sequence description for the current list of values.
The examples listed below are a subset of the overall list and show how to handle the different approaches.
- You can use some values without further information - for example, Initial.
- You will be required to combine some values with a date - for example, Response to Request for Information - 2014-03-30.
- You enter both the start and end dates for some values - for example, PSUR for Period of 2015-01-01 to 2015-06-30.
- You add a brief description (fewer than 40 characters) for other values - for example, Uncategorised, DESCRIPTION.
Example 1: Initial sequence
This example below shows how to specify the sequence description element for an initial sequence. The code for "Initial" is seq-desc-2 as specified in sequence-description.
<sequence-description code-version="4.0" code="seq-desc-2" />
Example 2: Response to a request for information
This example shows how to specify the sequence description element for responding to a request for information.
The code is seq-desc-5 as specified in sequence-description, where the complete text is defined as follows:
Response to Request for Information - {date:d}
In this case, a date is required as additional data. The name of the placeholder is date.
It requires an actual value in date format (as indicated by the letter d following the colon). The value has to be specified through a data child element of the sequence-description element as shown:
<sequence-description code-version="4.0" code="seq-desc-5"> <data use="date">2015-06-01</data></sequence-description>
Use the format YYYY-MM-DD for the actual date value wherever a date type placeholder is defined in the code lists.
The code version must be specified as an attribute code-version of the sequence-description element.
Example 3: PSUR with start and end dates
This example shows how to specify the sequence description element for a PSUR sequence with a PSUR start date of 2015-01-01 and a PSUR end date of 2015-06-30.
The code for "PSUR" is seq-desc-20 as specified in the defined list sequence-description, where the complete text is defined as follows:
PSUR for Period of {from-date:d} to {to-date:d}
In this text, two placeholders have been specified:
- the from-date
- the to-date.
Both placeholders require an actual value in date format (because of the letter 'd' following the colon).
These values have to be specified through data child elements of the sequence-description element as shown:
<sequence-description code-version="4.0" code="seq-desc-20"> <data use="from-date">2015-06-01</data> <data use="to-date">2015-12-01</data></sequence-description>
The code version must be specified as an attribute code-version of the sequence-description element. The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).
Related information and guidance
- sequence-description - Official defined lists for Sequence Description
- Sequence Matrix - A summary of which sequence descriptions can be used in combination with which sequence types.
Submission mode
Until the work grouping and work sharing functions are sufficiently developed, the only valid mode is 'single' which denotes a single regulatory activity.
Contact email
Sequences received will ultimately be validated through an automated process. Results of the validation will be sent to the email addresses provided. This email address will be contacted regarding any issues with validation of the sequence.
See the example XML code under Submitting multiple values.
It is the responsibility of the applicant to ensure that the email addresses provided in the envelope can receive emails with attachments, e.g. zip files, and that these emails do not get lost in SPAM.
Heading elements
The next 12 tables list the heading elements of the Australian CTD Module 1 v3.1.
Content under the following headings should be provided when required as defined in the Sequence Matrix.
Section ID | Business Terminology | XML-Element |
---|---|---|
1 | Correspondence | m1-0-correspondence |
1.0.1 | Cover letter | m1-0-1-cover |
1.0.2 | Lifecycle management tracking table | m1-0-2-tracking-table |
1.0.3 | Response to Request for Information | m1-0-3-response |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.2 | Administrative Information | m1-2-admin-info |
1.2.1 | Application forms | m1-2-1-app-form |
1.2.2 | Pre-submission details | m1-2-2-pre-sub-details |
1.2.3 | Patent certification | m1-2-3-pat-cert |
1.2.4 | Change in sponsor | m1-2-4-change-sponsor |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.3 | Medicine information and labelling | m1-3-med-info |
1.3.1 | Product information and package insert | m1-3-1-pi |
1.3.1.1 | Product information - clean | m1-3-1-1-pi-clean |
1.3.1.2 | Product information - annotated | m1-3-1-2-pi-annotated |
1.3.1.3 | Product information - approved | m1-3-1-3-pi-approved |
1.3.1.4 | Package insert | m1-3-1-3-pack-ins* |
1.3.2 | Consumer medicines information | m1-3-2-cmi |
1.3.2.1 | Consumer medicines information - clean | m1-3-2-1-cmi-clean |
1.3.2.2 | Consumer medicines information - annotated | m1-3-2-2-cmi-annotated |
1.3.2.3 | Consumer medicines information - approved | m1-3-2-3-cmi-approved |
1.3.3 | Label mock-ups and specimens | m1-3-3-mockup |
1.3.3.1 | Label mock-ups and specimens - clean | m1-3-3-1-mockup-clean |
1.3.3.2 | Label mock-ups and specimens - annotated | m1-3-3-2-mockup-annotated |
1.3.3.3 | Label mock-ups and specimens - approved | m1-3-3-3-mockup-approved |
*The section ID for Package insert has been updated but the element has been maintained to be consistent with previous specification versions.
Provide the Product information and Consumer medicines information in PDF format within the eCTD. Do not include working documents previously associated with NeeS submissions as they are not needed - for example, Microsoft Word source documents.
Section ID | Business Terminology | XML-Element |
---|---|---|
1.4 | Information about the experts | m1-4-experts |
1.4.1 | Quality | m1-4-1-quality |
1.4.2 | Nonclinical | m1-4-2-nonclinical |
1.4.3 | Clinical | m1-4-3-clinical |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.5 | Specific requirements for different types of applications | m1-5-specific |
1.5.1 | Literature-based submission documents | m1-5-1-lit-based |
1.5.2 | Designation applications - supporting documents | m1-5-2-orphan* |
1.5.3 | Genetically modified organisms consents | m1-5-3-gmo |
1.5.4 | Additional trade name declarations | m1-5-4-trade-name |
1.5.5 | Co-marketed medicines declarations | m1-5-5-co-marketed |
1.5.6 | Combination medicine consent | m1-5-6-comb-med |
1.5.7 | OTC product assurances | m1-5-7-prod-assurance |
1.5.8 | Umbrella brand assessment | m1-5-8-umbrella |
*The business terminology for Designation applications – supporting documents has been updated but the element has been maintained to be consistent with previous specification versions.
The 'document-matrix' XML file on the electronic submissions web page of the TGA website provides more information as to when documents are expected under these headings. In particular:
- 1.5.5 - Co-marketed medicines declarations should include the 'Letters of authorisation'.
- 1.5.6 - Combination medicine consent is relevant to prescription medicine applications.
- 1.5.7 - OTC product assurances are relevant to OTC applications.
- 1.5.8 - Umbrella brand assessment is relevant to OTC applications.
Section ID | Business Terminology | XML-Element |
---|---|---|
1.6 | Master files and certificates of suitability | m1-6-master-files |
1.6.1 | Relevant external sources | m1-6-1-ext-sources |
1.6.2 | Applicant's declaration | m1-6-2-app-decl |
1.6.3 | Letters of access | m1-6-3-loa |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.7 | Compliance with meetings and pre-submission processes | m1-7-compliance |
1.7.1 | Details of compliance with pre-submission meeting outcomes | m1-7-1-pre-sub |
1.7.2 | Details of any additional data to be submitted | m1-7-2-add-data |
1.7.3 | Declaration of compliance with pre-submission planning form and planning letter | m1-7-3-planning |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.8 | Information relating to Pharmacovigilance | m1-8-pv |
1.8.1 | Pharmacovigilance systems | m1-8-1-pv-systems |
1.8.2 | Risk management plan | m1-8-2-risk |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.9 | Summary of biopharmaceutic studies | m1-9-biopharm |
1.9.1 | Summary of bioavailability or bioequivalence study | m1-9-1-ba-be |
1.9.2 | Justification for not providing biopharmaceutic studies | m1-9-2-justification |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.10 | Information relating to paediatrics | m1-10-paediatrics |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.11 | Foreign regulatory information | m1-11-foreign |
1.11.1 | Foreign regulatory status | m1-11-1-status |
1.11.2 | Foreign product information | m1-11-2-pi |
1.11.3 | Data similarities and differences | m1-11-3-similarities |
1.11.4 | Foreign evaluation reports | m1-11-4-eval-reports |
Section ID | Business Terminology | XML-Element |
---|---|---|
1.12 | Antibiotic resistance data | m1-12-antibiotic |
Node extensions and leaf elements
Make title elements short, precise and informative. Do not repeat information already categorized by heading elements.
Place the most important identifying/distinguishing information at the beginning so we do not have to scroll to the end of the title.
You can repeat the optional node extension and leaf elements as required. The schema will ensure the checksum-type attribute contains either 'MD5' or 'md5'.
Node extensions
You can use node-extension elements:
- to define structures beyond the heading elements.
- wherever a leaf element is allowed in the schema.
- to organise multiple files which are needed under a normal eCTD heading.
The node-extension structure complies with general ICH eCTD specifications, but it is not a blanket permission to use the structures anywhere or without consideration. You may email esubmissions@health.gov.au for advice if the usage is novel.
The optional node-extension element contains a single mandatory title element, followed by at least one leaf element, and can be followed by another optional node-extension element.
Leaf elements
The leaf elements provide the content for each heading element.
This optional element contains, the title element along with a number of attributes, all based upon the ICH eCTD definition provided in the Electronic Common Technical Document Specification (Version 3.2.2).
Lifecycle operations
The following four lifecycle operations defined under the ICH eCTD specification:
- New
- Replace
- Delete
- Append.
We encourage you to:
- Use New, Replace, and Delete.
- Only use Append as part of the study tagging files (STF) as defined by the ICH eCTD Backbone File Specification for Study Tagging Files. If you use Append for any other purpose, you will:
- receive a validation warning
- need to include an explanation in the cover letter.
Specific lifecycle operations for Australia
The nodes with specific lifecycle operations mandated for an Australian eCTD are summarised in Table 18.
Section ID | Business Terminology | Lifecycle Operation |
---|---|---|
1.0 | Correspondence | |
1.0.1 | Cover letter | New |
1.0.2 | Lifecycle management tracking table | Replace* |
1.3 | Medicine information and labelling | |
1.3.1.1 | Product information - clean | Replace* |
1.3.1.2 | Product information - annotated | Replace* |
1.3.1.3 | Product information - approved | Replace* |
1.3.2.1 | Consumer medicines information - clean | Replace* |
1.3.2.2 | Consumer medicines information - annotated | Replace* |
1.3.2.3 | Consumer medicines information - approved | Replace* |
1.3.3.1 | Label mock-ups and specimens - clean | Replace* |
1.3.3.2 | Label mock-ups and specimens - annotated | Replace* |
1.3.3.3 | Label mock-ups and specimens - approved | Replace* |
1.8 | Information relating to Pharmacovigilance | |
1.8.2 | Risk management plan | Replace* |
1.11 | Foreign regulatory information | |
1.11.1 | Foreign regulatory status | Replace* |
Any use of Append outside the defined usage in Study Tagging Files |
*Except the first time we receive a document in which case the attribute should be 'New'.
For 1.8.2 use the lifecycle operator replace for Risk management plans. However in some instances, replace may not be appropriate - for example, when a new draft Risk management plan is submitted for consideration. When a final document is submitted, it will replace the draft. Thus it should be clear which Risk management plan is the current approved plan. If you use the lifecycle operator new, you:
- will receive a validation warning
- need to include a justification in the cover letter.
Files and folders
File and folder naming conventions
Naming conventions for the content files are not part of the validation criteria for eCTD.
You may use files submitted in other regions without re-naming, but:
- ensure all content is referenced by the appropriate XML files for efficient navigation
- provide precise but informative leaf titles to aid reviewers
- ensure the basic construction of the eCTD is maintained
- adhere to the naming conventions as described in Table 19
Naming conventions matrix
Folder | File | Description | |||
---|---|---|---|---|---|
e123456 | Application folder with eSubmission Identifier e.g. e123456 | ||||
0000 | Sequence folder with four-digit sequence number e.g. 0000 | ||||
index.xml | Index file in accordance with ICH | ||||
index-md5.txt | MD5 checksum in accordance with ICH | ||||
m1 | Content folder for Module 1 documents in accordance with ICH | ||||
au | Australia country specific folder | ||||
au-regional.xml | Australia regional index file for Module 1 | ||||
m2 | Content folder for Module 2 documents in accordance with ICH | ||||
m3 | Content folder for Module 3 documents in accordance with ICH | ||||
m4 | Content folder for Module 4 documents in accordance with ICH | ||||
m5 | Content folder for Module 5 documents in accordance with ICH | ||||
util | Util folder in accordance with ICH | ||||
dtd | DTD and schema folder in accordance with ICH | ||||
au-regional.xsd | Australia regional backbone schema for Module 1 | ||||
xlink.xsd | W3C schema for XLink 1.1 (referenced from au-regional.xsd) | ||||
xml.xsd | W3C schema for XML namespace (referenced from au-regional.xsd) | ||||
ich-ectd-3-2.dtd | ICH DTD for Modules 2 to 5 | ||||
style | Style sheet folder in accordance with ICH (optional) | ||||
ectd-2-0.xsl | ICH style sheet for Modules 2 to 5 (optional) | ||||
au-regional.xsl | Style sheet for Australian regional backbone (optional) |
Folder and file name-path length
Ensure the overall length of the folder and file name path, starting from the sequence number, does not exceed 180 characters, for any file in any module.
We acknowledge it is less than the ICH agreed overall path length.