Documente online.
Zona de administrare documente. Fisierele tale
Am uitat parola x Creaza cont nou
 HomeExploreaza
upload
Upload




SGML Primer for users of the OFC DTD

software


SGML Primer for users of the OFC DTD 13313i815n

The Document Type Definition (DTD 13313i815n ) vs. The Document

The DTD 13313i815n is what defines the legal format of an SGML document. For example, the OFC DTD 13313i815n contains the rules for the legal format of an OFC file (the SGML document). These rules are what defines the behavior of the parser used by Money and an OFC server. If the OFC file does not comply to the rules of the DTD 13313i815n , the parser must reject the OFC file.



DTD 13313i815n

Markup Declarations - the DTD 13313i815n is simply a list of markup declarations

<! Keyword Tagname Associated Parameters >

Keywords and associated syntax

DOCTYPE - uniquely defines which DTD 13313i815n you are about to define, (for example OFC).

<!DOCTYPE OFC [ the markup declarations ]>

ELEMENT - defines an 'object' within the logical structure of the document. In defining an element, there are two characters that follow the tagname that indicate the requirements of using an element within the document (this is known as minimization). The first indicates the requirements of the opening tag, and the second the requirements of the closing tag. A dash indicates that the tag is required. The letter o indicates that the tag is optional. In the example that follows, the opening tag for a FOO is required, but the closing tag is optional.

<!ELEMENT TAGNAME - o ( the content model )>

ENTITY - this is an alias for another parameter or list of parameters, kind of like #define in C (must be listed at the top of the DTD 13313i815n ).

<!ENTITY % NAME "the content model to put in it's place ">

There are several others, but OFC does not use them.

Content model

Sequential - Commas ( , ) define a fixed order of elements. For example,

(x, y, z)

requires an x element, followed by a y element, followed by a z element.

Optional - Question marks ( ? ) define completely optional elements. For example,

(x, y?, z)

requires an x element, optionally followed by a y element, followed by a z element.

Optional choice - Vertical bars ( | ) represent a logical or among a set of elements. For example,

(x, (y | z))

requires an x element, followed by either a y element or a z element, but not both.

Optional but repeatable - Asterisks ( * ) define elements that are optional, but can be sequentially repeated, with no limits. For example,

(x, y, z*)

requires an x element, followed by a y element, followed by zero or more z elements.

Required and repeatable - Plus signs (+) define elements which require at least one entry, but can be sequentially repeated, with no limit. For example,

(x, y, z+)

requires an x element, followed by a y element, followed by one or more z elements.

Required but in any order - Ampersands ( & ) defines required elements where order is not important. For example,

(x, y & z)

requires an x element, followed by either a y element and then a z element or a z element and then a y element.

Comments

<!-- Comments can be included using this format!!! -->

#PCDATA

#PCDATA (parsable character data) is a notation that defines where actual data can legally follow a tagname. Data can only be located in these locations, otherwise the document will be considered illegal in format.

The OFC DTD 13313i815n

We only use element and entity keywords at this point for describing the data in an OFC file.

We build up the file using the following functional 'objects' entities to describe the OFC data, each defined in terms of an ELEMENT declaration: transactions, aggregates, single elements.

The ENTITY declarations attempt to encapsulate the parsing rules of the individual OFC data formats that follow an element tag.

The content model for a single element must always contain one of the entity keywords, never #PCDATA directly. This is because the parser must know which type of data stream to expect when it encounters a given element.

Aggregates define logical groups of elements that always have common ordering of the data. An example of this would be an account.

We use a nested format for describing the set of transactions, with two basic types of transactions at the outermost level; maintenance and financial.


Document Info


Accesari: 866
Apreciat: hand-up

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta


Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site


in pagina web a site-ului tau.




eCoduri.com - coduri postale, contabile, CAEN sau bancare

Politica de confidentialitate | Termenii si conditii de utilizare




Copyright © Contact (SCRIGROUP Int. 2024 )