Требования к XML и требования к XML-каналу

В фиде, помимо описанных ниже тегов, должно быть дерево категорий. Все товары в фиде должны ссылаться на какую-либо из категорий из этого дерева (при помощи тега categoryId), иначе они не будут обработаны. Если дерева категорий нет, то генерации не будет.

Пример дерева категорий:

Теги в XML-фиде

* теги в фиде должны иметь такие же названия, какие представлены в требованиях к  XML-фиду; однако, на шаге №2 в Генераторе можно переопределить некоторые названия тегов и выбрать свои, если они представляют аналогичные по сути вещи

<offer>

• категория в товаре должна находиться в шапке категорий в фиде, иначе мы не будем обрабатывать такой товар
• если категорий для товара указано несколько, будет выбрана только одна (первая указанная)

<picture> – ссылка на изображение

• обязателен, – если его нет, то появится ошибка в интерфейсе
• лучше всего, когда тип товара (например, “шуруповерт” или “платье”) идет в начале тега name, а доп.информация разделена запятыми (либо любыми другими знаками препинания). Всякого рода названия (например, название книги, скажем, “Дети капитана Гранта”) лучше всего указывать в кавычках “”, чтобы Генератор не разделил их на отдельные слова (и не стал рекламировать отдельно детей и гранты)

<vendor> – производитель

• опционален, но семантика будет лучше, если его указать
• если описание не сильно связано с самим товаром (например, товар – бумажная модель танка, а в описании товара пространно описывается Вторая Мировая, то и семантика будет скорее не про товар, а про войну), то, возможно, лучше не стоит указывать данный тег для обработки

<param> – доп. информация о товаре

На шаге №2 “Обработка полей в XML” в Генераторе указываются соответствия между понятными Генератору сущностями и некоторыми тегами в фиде

По умолчанию, в Генераторе используются следующие соответствия:

Пример хорошего товара (1):

Пример хорошего товара (2):

Пример хорошего товара (3):

1 Introduction

XML documents are made up of storage units called entities,
which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character
data, and some of which form markup.
Markup encodes a description of the document’s storage layout and logical
structure. XML provides a mechanism to impose constraints on the storage layout
and logical structure.

2 Terminology

Each XML document has both a logical and a physical structure. Physically,
the document is composed of units called entities.
An entity may
refer to other entities to
cause their inclusion in the document. A document begins in a “root”
or document entity. Logically, the document
is composed of declarations, elements, comments, character references, and
processing instructions, all of which are indicated in the document by explicit
markup. The logical and physical structures MUST nest properly, as described
in 4.3.2 Well-Formed Parsed Entities.

1 Well-Formed XML Documents

• Taken as a whole, it matches the production labeled document.
• It meets all the well-formedness constraints given in this specification.
• Each of the parsed entities
  which is referenced directly or indirectly within the document is well-formed.

Matching the document production implies that:

2 Characters

This section defines some symbols used widely in the grammar.

S (white space) consists of one or more space (#x20)
characters, carriage returns, line feeds, or tabs.

White Space

An Nmtoken (name token) is any mixture of name
characters.

The first character of a Name MUST be a NameStartChar, and any
other characters MUST be NameChars; this mechanism is used to
prevent names from beginning with European (ASCII) digits or with
basic combining characters. Almost all characters are permitted in
names, except those which either are or reasonably could be used as
delimiters. The intention is to be inclusive rather than exclusive,
so that writing systems not yet encoded in Unicode can be used in
XML names. See J Suggestions for XML Names for suggestions on the creation of
names.

Document authors are encouraged to use names which are
meaningful words or combinations of words in natural languages, and
to avoid symbolic or white space characters in names. Note that
COLON, HYPHEN-MINUS, FULL STOP (period), LOW LINE (underscore), and
MIDDLE DOT are explicitly permitted.

The ASCII symbols and punctuation marks, along with a fairly
large group of Unicode symbol characters, are excluded from names
because they are more useful as delimiters in contexts where XML
names are used outside XML documents; providing this group gives
those contexts hard guarantees about what cannot be part of
an XML name. The character #x037E, GREEK QUESTION MARK, is excluded
because when normalized it becomes a semicolon, which could change
the meaning of entity references.

Names and Tokens

The Names
and Nmtokens productions are used to define the validity
of tokenized attribute values after normalization (see 3.3.1 Attribute Types).

Literal data is any quoted string not containing the quotation mark used
as a delimiter for that string. Literals are used for specifying the content
of internal entities (EntityValue), the values
of attributes (AttValue), and external identifiers
(SystemLiteral). Note that a SystemLiteral
can be parsed without scanning for markup.

Literals

To allow attribute values to contain both single and double quotes, the
apostrophe or single-quote character (‘) may be represented as ”
&apos;
“,
and the double-quote character (“) as ”
&quot;
“.

PIs are not part of the document’s character
data, but MUST be passed through to the application. The PI begins
with a target (PITarget) used to identify the application
to which the instruction is directed. The target names ”
XML
“, ”
xml
“,
and so on are reserved for standardization in this or future versions of this
specification. The XML Notation mechanism
may be used for formal declaration of PI targets. Parameter
entity references MUST NOT be recognized within processing instructions.

7 CDATA Sections

Within a CDATA section, only the CDEnd string is
recognized as markup, so that left angle brackets and ampersands may occur
in their literal form; they need not (and cannot) be escaped using ”
&lt;
”
and ”
&amp;
“. CDATA sections cannot nest.

8 Prolog and Document Type Declaration

and so is this:

The document type declaration MUST appear before the first element
in the document.

Even though the VersionNum production matches
any version number of the form ‘1.x’, XML 1.0 documents SHOULD NOT specify a version number other than ‘1.0’.

When an XML 1.0 processor encounters a document that specifies
a 1.x version number other than ‘1.0’, it will process it as
a 1.0 document. This means that an XML 1.0 processor will accept
1.x documents provided they do not use any non-1.0 features.

Document Type Definition

Note
that it is possible to construct a well-formed document containing a doctypedecl
that neither points to an external subset nor contains an internal subset.

The markup declarations may be made up in whole or in part of the replacement text of parameter
entities. The productions later in this specification for individual
nonterminals (elementdecl, AttlistDecl,
and so on) describe the declarations after all the parameter
entities have been included.

Parameter
entity references are recognized anywhere in the DTD (internal and external
subsets and external parameter entities), except in literals, processing instructions,
comments, and the contents of ignored conditional sections (see 3.4 Conditional Sections).
They are also recognized in entity value literals. The use of parameter entities
in the internal subset is restricted as described below.

Like the internal subset, the external subset and any external parameter
entities referenced
in a DeclSep
MUST consist of a series of
complete markup declarations of the types allowed by the non-terminal symbol markupdecl, interspersed with white space or parameter-entity references. However, portions of
the contents of the external subset or of these
external parameter entities may conditionally be ignored by using the conditional section construct; this is not
allowed in the internal subset but is
allowed in external parameter entities referenced in the internal subset.

External Subset

The external subset and external parameter entities also differ from the
internal subset in that in them, parameter-entity
references are permitted within markup declarations,
not only between markup declarations.

An example of an XML document with a document type declaration:

The system identifier
”
hello.dtd
”
gives the address (a URI reference) of a DTD for the document.

The declarations can also be given locally, as in this example:

If both the external and internal subsets are used, the internal subset
MUST be considered to occur before the external subset.
This has the effect that entity and attribute-list declarations in the internal
subset take precedence over those in the external subset.

9 Standalone Document Declaration

In a standalone document declaration, the value “yes” indicates
that there are no external markup declarations which
affect the information passed from the XML processor to the application. The
value “no” indicates that there are or may be such external
markup declarations. Note that the standalone document declaration only denotes
the presence of external declarations; the presence, in a document,
of references to external entities, when those entities are internally
declared, does not change its standalone status.

If there are no external markup declarations, the standalone document declaration
has no meaning. If there are external markup declarations but there is no
standalone document declaration, the value “no” is assumed.

Any XML document for which standalone=”no” holds can be converted
algorithmically to a standalone document, which may be desirable for some
network delivery applications.

Validity constraint: Standalone Document Declaration

The
standalone document declaration MUST have the value “no” if
any external markup declarations contain declarations of:

An example XML declaration with a standalone document declaration:

10 White Space Handling

In editing XML documents, it is often convenient to use “white space”
(spaces, tabs, and blank lines)
to set apart the markup for greater readability. Such white space is typically
not intended for inclusion in the delivered version of the document. On the
other hand, “significant” white space that should be preserved
in the delivered version is common, for example in poetry and source code.

An XML processor
MUST always pass
all characters in a document that are not markup through to the application.
A validating XML processor
MUST also
inform the application which of these characters constitute white space appearing
in element content.

A special attribute named xml:space may be attached to an element to signal an intention that in that element,
white space should be preserved by applications. In valid documents, this
attribute, like any other, MUST be declared
if it is used. When declared, it MUST be given as an enumerated
type whose values
are one or both of “default” and “preserve”.
For example:

The value “default” signals that applications’ default white-space
processing modes are acceptable for this element; the value “preserve”
indicates the intent that applications preserve all the white space. This
declared intent is considered to apply to all elements within the content
of the element where it is specified, unless overridden with
another instance of the xml:space attribute. This specification does not give meaning to any value of xml:space other than “default” and “preserve”. It is an error for other values to be specified; the XML processor MAY report the error or MAY recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values.

The root element of any document is considered
to have signaled no intentions as regards application space handling, unless
it provides a value for this attribute or the attribute is declared with a
default value.

11 End-of-Line Handling

XML parsed entities are often stored
in computer files which, for editing convenience, are organized into lines.
These lines are typically separated by some combination of the characters
CARRIAGE RETURN (#xD) and LINE FEED (#xA).

12 Language Identification

(Productions 33 through 38 have been removed.)

The language specified by xml:lang applies to the element where it is specified
(including the values of its attributes), and to all elements in its content unless
overridden with another instance of xml:lang. In particular, the empty value of xml:lang is used on an element B to override
a specification of xml:lang on an enclosing element A, without specifying another language. Within B,
it is considered that there is no language information available, just as if xml:lang had not been specified
on B or any of its ancestors. Applications determine which of an element’s attribute values
and which parts of its character content, if any, are treated as language-dependent values described by xml:lang.

Language information may also be provided by external transport protocols (e.g. HTTP or
MIME). When available, this information may be used by XML applications, but the more local
information provided by xml:lang should be considered to override it.

A simple declaration for xml:lang might take the form

but specific default values may also be given, if appropriate. In a collection
of French poems for English students, with glosses and notes in English, the xml:lang
attribute might be declared this way:

3 Logical Structures

Validity constraint: Element Valid

2 Element Type Declarations

The element structure of an XML document may, for validation
purposes, be constrained using element type and attribute-list declarations.
An element type declaration constrains the element’s content.

where the Name gives the element type being declared.

Examples of element type declarations:

1 Element Content

Validity constraint: Proper Group/PE Nesting

Parameter-entity replacement text
MUST be properly nested with parenthesized
groups. That is to say, if either of the opening or closing parentheses in
a choice, seq, or Mixed
construct is contained in the replacement text for a parameter
entity, both MUST be contained in the same replacement text.

Examples of element-content models:

3 Attribute-List Declarations

Attributes are used to associate name-value
pairs with elements. Attribute specifications
MUST NOT appear outside of start-tags and empty-element tags; thus, the productions used to
recognize them appear in 3.1 Start-Tags, End-Tags, and Empty-Element Tags. Attribute-list declarations
may be used:

• To define the set of attributes pertaining to a given element type.
• To establish type constraints for these attributes.
• To provide default values for
  attributes.

Before the value of an attribute is passed to the application or checked
for validity, the XML processor MUST normalize the attribute value by applying
the algorithm below, or by using some other method such that the value passed
to the application is the same as that produced by the algorithm.

• All line breaks MUST have been normalized on input to #xA as described
  in 2.11 End-of-Line Handling, so the rest of this algorithm operates
  on text normalized in this way.
• Begin with a normalized value consisting of the empty string.
• For a character reference, append the referenced character to the
  normalized value.For an entity reference, recursively apply step 3 of this algorithm
  to the replacement text of the entity.For a white space character (#x20, #xD, #xA, #x9), append a space
  character (#x20) to the normalized value.For another character, append the character to the normalized value.
• For a character reference, append the referenced character to the
  normalized value.
• For an entity reference, recursively apply step 3 of this algorithm
  to the replacement text of the entity.
• For a white space character (#x20, #xD, #xA, #x9), append a space
  character (#x20) to the normalized value.
• For another character, append the character to the normalized value.

If the attribute type is not CDATA, then the XML processor MUST further
process the normalized attribute value by discarding any leading and trailing
space (#x20) characters, and by replacing sequences of space (#x20) characters
by a single space (#x20) character.

Note that if the unnormalized attribute value contains a character reference
to a white space character other than space (#x20), the normalized value contains
the referenced character itself (#xD, #xA or #x9). This contrasts with the
case where the unnormalized value contains a white space character (not a
reference), which is replaced with a space character (#x20) in the normalized
value and also contrasts with the case where the unnormalized value contains
an entity reference whose replacement text contains a white space character;
being recursively processed, the white space character is replaced with a
space character (#x20) in the normalized value.

All attributes for which no declaration has been read SHOULD be treated
by a non-validating processor as if declared CDATA.

It is an error if an attribute
value contains a reference to an
entity for which no declaration has been read.

the attribute specifications in the left column below would be normalized
to the character sequences of the middle column if the attribute a
is declared NMTOKENS and to those of the right columns if a
is declared CDATA.

Note that the last example is invalid (but well-formed) if a
is declared to be of type NMTOKENS.

4 Conditional Sections

Like the internal and external DTD subsets, a conditional section may contain
one or more complete declarations, comments, processing instructions, or nested
conditional sections, intermingled with white space.

If the keyword of the conditional section is a parameter-entity reference,
the parameter entity MUST be replaced by its content before the processor
decides whether to include or ignore the conditional section.