Schema Languages & Internationalization Issues: A survey

2.1.1 Internationalization and localization related to XML

Content or software which is authored in one language (so-called original language) often has to be made available in additional languages. Translation and other activities related to this making available thus are an important factor in production processes related to content or software.

I18n [internationalization] is the process of generalizing a product so that it can handle multiple languages and cultural conventions without the need for redesign. Internationalization takes place at the level of program design and document development.

L10n [localization] is the process of taking a product and making it linguistically and culturally appropriate to a given target locale (country / region and language) where it will be used.

With XML entering the stage in both the content (e.g. the XML version of DocBook [Walsh and Muellner 1999], a format related to software manuals) and the software world (e.g. XUL [eXtensible User Interface Language], cf.
http://www.xulplanet.com/), new challenges and chances related to efficient and high-quality translation / internationalization arise, cf. [Savourel (2001)]. Some sample challenges are:

(1) For each XML vocabulary, possibly all people, processes and tools have to be made aware of specifics such as which attributes or elements contain translatable content, see figure 1.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Sample XUL file -->
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
 <box align="center">
  <button label="hello xFly" onclick="alert('Hello World');"/>
 </box>
</window>

(2) Translation may break certain types of coding. If for example an application requires titles of chapters to be unique, but translation does not adhere to this constraint, the application may fail to work.

Some sample chances are:

(1) XML-based material can be much more easily twisted than binary content. It is for example easy to extract the value of certain attributes by means of a very basic XSL stylesheet.

(2) Information which is helpful for translation / localization purposes often can be embedded or attached to XML-based material. This very often holds for both the specification of an XML vocabulary (e.g. in XML Schema) and for XML documents. Figure 2 gives an example.

<xsd:schema xmlns="http://example.com/myBook" 
xmlns:slim="http://www.example.com/slim"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified" 
targetNamespace="http://example.com/myBook">
 <xsd:element name="book">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element ref="chapter" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
  <xsd:unique name="titleIdAndContent" slim:noteToLocEng="Please check that
this constraint can be enforced in our target languages">
   <xsd:selector xpath="chapter"/>
   <xsd:field xpath="@title"/>
  </xsd:unique>
 </xsd:element>
 <xsd:element name="chapter">
  <xsd:complexType mixed="true">
   <xsd:attribute name="title" use="required"/>
   <xsd:attribute name="id" use="optional" type="xsd:ID"/>
  </xsd:complexType>
 </xsd:element>
</xsd:schema>

The figure contains a sample XML Schema with i18n / l10n Information. It provides a uniqueness constraint slim:noteToLocEng (see section 4.1.2) for a localization engineer.

2.1.2 The need for additional i18n and l10n support in XML contexts

As indicated in the remarks above, a standard set of information / data categories that can be used with XML material (both schemas and XML instances) to support the internationalization and localization of documents would be helpful.

What kind of i180n- and l10n-related information is needed in a certain XML usage scenario, and how it can be captured depends on the scenario. Some vocabularies and processing pipelines

• center on prose
• focus on code (XUL, cf. figure 1)
• mix prose and code (e.g. DocBook)
• include presentational aspects (e.g. XHTML).

Examples are given in figure 3.

DOCBOOK EXAMPLE:
<book lang="en-US">
 <title>Introduction to Python</title>
  <chapter>
   <title>Basics</title>
    <para>This is a simple example of the Python interpreter.</para>
    <example>
    <title>The Python interpreter</title>
     <programlisting format="linespecific"><![CDATA[
>>> s = 'Hello, world.'
>>> str(s)
'Hello, world.'
]]></programlisting>
    </example>
  <para>If you create a typing error like "strs(s)",
   you will get the message "NameError: name 'strs' is not defined".</para>
 </chapter>
</book>
TEI EXAMPLE:
<TEI.2>
 <teiHeader>
  <fileDesc>
   <titleStmt>
    <title>Japanese: An Introduction</title>
   </titleStmt>
    <publicationStmt>
     <date>5 May 2005</date>
    </publicationStmt>
    <sourceDesc><p>Initial Draft</p></sourceDesc>
  </fileDesc>
 </teiHeader>
 <text>
  <body>
   <div1>
    <head><title>Honorific Expressions</title></head>
    <p>The <term  id="honor-expr">Plain Style(普通語)</term> versus
     the <term id="polite-expr">Polite Style(丁寧語)</term> ...</p>
   </div1>
  </body>
 </text>
</TEI.2>
XHTML 1.0 EXAMPLE:
<html xmlns="http://www.w3.org/1999/xhtml"
 xml:lang="en-US" lang="en-US"> 
 <head>
  <title>World News - 2 May 2005</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> 
  <style type="text/css">
   h1 {color: blue; text-align:center}
  </style>
 </head>
 <body>
  <h1>World News - 2 May 2005</h1>
  <h2>Germany: The first Female Chancelor</h2>
  <p>...</p>
 </body>
</html>

DocBook is an example of a vocabulary that mixes prose and code. The code (see the content of the programlisting element) must not be translated in certain processing / production contexts (or only parts of it like the Hello World phrase may have to be translated). In the example from the TEI [Text Encoding Initiative] ([Sperberg-McQueen et al. 1994]), textual data is in the centre. Here the term element ³ might rely on an external data base for linguistic terminology.

XHTML 1.0 [Pemperton et al. (2000)] allows for the inclusion of presentational information. Accordingly, the style element might need adaptation, when the content is localized. An example for XML which contains only software code is XUL, cf. figure 1.

The examples show that each XML context (e.g. the underlying schema or the processing for a certain bit of content) raises specific issues related to i18n / l10n. Although i18n related information which is helpful for localization purposes often can be embedded or attached to XML-based material (a noteworthy example is the identification of a language via the xml:lang attribute), a need exists for a standard related to i18n and l10n facilitating information in XML. In lack of a standard tool support for i18n and l10n it might not be possible to realize these processes efficiently (since e.g. each XML vocabulary may choose its own way to represent information which a localizer should know about). The W3C ITS WG accordingly addresses this need and works on data categories, representation mechanisms and guidelines related to i18n and l10n support in XML contexts.

4.1.1 Existing schema languages

A few years ago, a lively discussion about various schema languages took place, and the variety of schema languages was immense. One reason for this discussion was unclearness about the formal properties of schema languages. The clearness needed was provided by [Murata et al. 2001], who described schema languages in terms of formal language theory, relying on the framework of regular tree grammars. Today, mainly three alternative schema languages remain, i.e.

• XML-DTDs, a local tree grammar. It allows only one definition of an element with the same name and the same content model, i.e. it is forbidden to declare a p element several times.
• XML Schema, a single type tree grammar. It allows for the declaration of elements with the same name and different content models in different contexts, e.g. (1) a p element inside a footnote element; the p element has only textual content (2) a p element inside a div element; the p element has a content model with child elements. The UPA [unique particle attribution] constraint⁴ disallows the definition of an element with the same name several times in the same context. E.g. XML schema would not allow (1) and (2) to be part of the same content model, e.g. of the same div element.
• RELAX NG, which can be described as a regular tree grammar. It has no constrains on the structure of content models. Elements with the same name but different content models are allowed in the same context, e.g. the variants of a p element mentioned above.

Beside these grammar-based schema languages, the so-called pattern-based schema language exist [Lee and Chu]. For the purposes of ITS, the pattern-based schema language Schematron (cf.
http://www.schematron.com/), is highly valuable as well. Nonetheless, at the moment the ITS activities mainly deal with the grammar-based schema languages.

Figure 6 provides schemas for the documents in figure 3. As for the DocBook document , it is assumed that the schema is given as an XML DTD. For the TEI document, an RELAX NG Schema has been created. It is written here with the compact syntax of RELAX NG. The XHTML 1.0 example relies on XML Schema.

DTD for the DocBook document:
<!ELEMENT book (title,chapter)>
<!ATTLIST book
 lang  NMTOKEN #REQUIRED>
<!ELEMENT chapter (title,(example|para)+)>
<!ELEMENT example (title,programlisting)>
<!ELEMENT para (#PCDATA)>
<!ELEMENT programlisting (#PCDATA)>
<!ATTLIST programlisting
 format  CDATA #FIXED 'linespecific'>
<!ELEMENT title (#PCDATA)>
RELAX NG Schema in compact syntax for the TEI document:
start =
  element TEI.2 {
    element teiHeader {
      element fileDesc {
        element titleStmt { title },
        element publicationStmt {
          element date { text }
        },
        element sourceDesc { p }
      }
    },
    element text {
      element body { div1+ }
    }
  }
div1 =
  element div1 {
    element head { title },
    p
  }
title = element title { text }
p =
  element p {
    (text
     | element term {
         attribute id { xsd:NCName },
         text
       })+
  }
  
XML Schema for the XHTML 1.0 example document:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"  
 xmlns="http://www.w3.org/1999/xhtml"  
 targetNamespace="http://www.w3.org/1999/xhtml"
 elementFormDefault="qualified">
 <xs:element name="html">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="head"/>
    <xs:element ref="body"/>
   </xs:sequence>
   <xs:attribute name="lang" type="xs:NMTOKEN" use="required"/>
  </xs:complexType>
 </xs:element>
 <xs:element name="head">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="title" type="xs:string"/>
    <xs:element name="meta">
     <xs:complexType>
      <xs:attribute name="http-equiv" type="xs:NMTOKEN" use="optional"/>
      <xs:attribute name="content" type="xs:string" use="required"/>
     </xs:complexType>
    </xs:element>
    <xs:element name="style">
     <xs:complexType mixed="true">
      <xs:attribute name="type" type="xs:string" use="required"/>
     </xs:complexType>
    </xs:element>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
 <xs:element name="body">
  <xs:complexType mixed="true">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
     <xs:element name="h1" type="xs:string"/>
     <xs:element name="h2" type="xs:string"/>
     <xs:element name="p" type="xs:string"/>
    </xs:choice>
   </xs:complexType>
 </xs:element>
</xs:schema>

It is assumed that the reader is familiar with the syntax of XML DTDs. In the RELAX NG schema, the root element of the document is defined via the keyword start, e.g. start = element TEI.2. The element keyword is used for element declarations. Content models are given in curly brackets, e.g. element TEI.2 { ...}. Attributes are declared with the keyword attribute, e.g. attribute id { ... }. As for the content of elements and attributes, the keyword text signals textual data. Other data types are possible as well, e.g. the data type xsd:NCName. RELAX NG allows for the definition of named patterns, which can be referenced within other declarations. An example is the pattern div1, which is referenced in the content model of the body element.

XML Schema is defined in an XML based Syntax. The example schema contains element declarations, e.g. <xs:element name="html"> ..., attribute declarations, e.g. <xs:attribute name="lang" ... > ..., and type definitions, e.g. with the xs:complexType element. Types will be discussed later in section 4.1.2. Each element or attribute needs to have a non-ambiguous type. Types can have names, e.g. xs:NMTOKEN for the attribute lang, or they can be defined without a name. The elements in the schema are defined with complex types. If the elements should contain textual data and child elements or attributes, the complex type definition has an attribute mixed="true". Global declarations of elements and attributes, i.e. declarations under the xs:schema element, can be referenced. In the example, the content model of the html element makes references to the elements head and body.

4.1.2 Features of schema languages and their relation to ITS

For the realization of ITS, the features of schema languages which are summarized in the following table are of importance. The table also describes the position of the schema languages which respect to the framework of regular tree grammars mentioned above.

Pattern based descriptions are only possible with Schematron, which relies on XPath. Using XPath 2.0 [Berglund et al. (2005)] which allows for selection of information across documents, the requirement of uniqueness from various documents (see requirement 1 in section 3) can be fulfilled. The XML Syntax which is provided by all schema languages except XML DTDs⁵ is an important means for the processing of ITS data categories in schemas in general. If for example ITS data categories / requirements are incompatible with an existing schema, an XSLT based filter can be used to create two versions of the schema: One with ITS specific additions, the other as the basic schema. A similar filter can be applied to documents. In this way, existing processing chains (requirement 5 in section 3) like validation can be maintained.

Namespaces are provided by all schema languages, with a limited support in XML DTDs⁶. To avoid conflicts between existing schemas and ITS related markup (requirement 6 in section 3), they are an important means. Nevertheless they do not solve all problems: If a version of ITS relies on markup from one scheme, e.g. XHTML 1.0, that markup might not be available in a different version of the scheme (requirement 7 in section 3).

The data typing facilities provided by the various schema languages lead to many differences between them. Data typing for attribute values is provided by all schema languages, except Schematron⁷. Only RELAX NG and XML Schema allow for typing for simple content in elements. In this way it is possible to state that the content of the date element in the TEI document in Figure 3 has to be of the type date. This makes it possible to provide date and time related information for the localization process. Datatyping for complex content, i.e. for elements with attributes and / or child elements, is only possible with XML Schema. Together with the subtyping mechanism of XML Schema, this is a powerful mean to avoid incompatibility with existing schemas (requirement 4 in section 3). The following example, which is based on the XHTML example in Figure 3, demonstrates how subtyping can be used to add ITS specific information to a schema:

<xs:complexType name="paraContent" mixed="true">
 <xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:complexType>
<xs:complexType name="itsParaContent">
 <xs:complexContent>
 <xs:extension base="paraContent">
  <xs:attribute name="locinfo" type="xs:string"/>
 </xs:extension>
</xs:complexContent>
</xs:complexType>
...
<xs:element name="p" type="itsParaContent"/>

A mechanism which is different, but yet in some respect similar to these typing mechanisms, are grouping and modularization facilities. These are provided by all schema languages except Schematron. Nevertheless, the details of these facilities differ between each schema language. Some examples are introduced here for XML DTDs, and RELAX NG, and then compared to data typing.

With the combined application of parameter entities and marked sections in XML DTDs, definitions like the following are possible:

<!ENTITY % para "INCLUDE">
<![%para;[
   <!ELEMENT p (#PCDATA)> 
   <!ATTLIST p id ID #IMPLIED> 
   <!ENTITY % i18n.para "IGNORE">
]]>
<![%i18n.para;[
   <!ELEMENT p (#PCDATA)> 
   <!ATTLIST p 
     id ID #IMPLIED
     locinfo CDATA #IMPLIED> 
]]>

p = p-common | p-i18n
p-common =
  element p {
    attribute id { xsd:ID },
    text
  }
p-i18n =
  p-common,
  attribute locinfo { text }
element div = p+

XML Schema provides a similar grouping mechanism. The difference is that in the case of XML Schema, the groups must not lead to grammar patterns which exceed the power of a single type tree grammar. For example, the definition p = p-common | p-i18n from the RELAX NG example leads to two p elements with different content models. These are then used in the same context, i.e. in the content model of the div element. As mentioned before, this is not possible in XML Schema.

The following table summarizes the differences between marked sections in XML DTDs, type derivations in XML Schema and grouping with named patterns in RELAX NG.

The key difference between the grouping or modularization mechanisms and subtyping is that grouping provides only information in the schema. As for the validation of XML documents against the schema, this information is just "syntactic sugar". It is not accessible for or after the validation process. This is the crucial difference to the typing approach of XML Schema: After validation, typing information is available in the PSVI [Post Schema Validation Infoset]⁸. For example, the PSVI provides information about the type of a p element, e.g. whether it is of the complex type itsParaContent. This information can be used for further processing. A query in XQuery [Boag et al 2003] which retrieves all elements with the type itsParaContent would be

for $itsPara in doc("mydoc.xml")//element(*, itsParaContent?) return $itsPara

Uniqueness constraints, the last property of schema languages to be discussed in this section are uniqueness constraints. They are only available in XML Schema. They allow to specify e.g. that during the localization of an XUL document, the values of the label and onclick attributes always form a unique combination:

<xsd:unique name="uniqueButton">
 <xsd:selector xpath="button"/>
 <xsd:field xpath="@label"/>
 <xsd:field xpath="@onclick"/>
</xsd:unique>

<schema xmlns="http://www.ascc.net/xml/schematron" >
 <pattern name="uniqueButton">
  <rule context="window">
   <assert test="
exists(
 if (count(distinct-values(
  for $i in .//button
  return (concat($i/@label, concat(' ',$i/@onclick))))) &lt; count (for $i in $input//a
  return $i))
 then 'error found' else ''
)"
 >The values of the label attribute and
 the onclick attribute are not in a unique combination.</assert>
  </rule>
 </pattern>
</schema>

4.3.1 Architectural forms

Architectural forms are defined in Annex A of the HyTime standard [ISO/IEC10744]¹⁰. Their purpose is to describe relations between schemas in the format of SGML or XML DTDs. The relations are sets of mapping rules. Each set of rules is an archform with a name, e.g. the archfom its-arch. Figure 8 shows an architectural form.

XML DOCUMENT:
<!DOCTYPE html SYSTEM "xhtml-plus-its.dtd">
<html>
<head>...</head>
<body>...
<its-span title="This needs special handeling"></its-span>
</body>
</html>
CLIENT DTD "xhtml-plus-its.dtd":
<?IS10744:arch name="its-arch"
  bridge-form="archbridge"
  renamer-att="its-arch.atts"
  dtd-system-id="xhtml1-transitional.dtd"?>
<!ELEMENT html (head, body)>
<!ATTLIST html its-arch NAME #FIXED "archbridge">
...
META DTD "xhtml1-transitional.dtd":
<!ELEMENT html (head, body)>
...
<!ELEMENT span (#PCDATA)>
<!ATTLIST span title CDATA #IMPLIED>
...
<!ELEMENT its-span (#PCDATA)>
<!ATTLIST its-span its-arch NAME #FIXED "span"
 its-arch.atts CDATA #FIXED "locinfo title">
...

The XML document, to which the architecture should be applied to, refers to the DTD xhtml-plus-its.dtd. In the terminology of architectural forms, this is the client dtd. The DTD to which the client dtd is being related, is called meta dtd. In the client DTD, the architecture is identified by the processing instruction ISO10744 which defines the name of the architecture. The architecture is applied via attribute declarations in the client dtd. In the case of the its-span element, there are two attributes:

<!ATTLIST its-span
its-arch NAME #FIXED "span"
arch.atts CDATA #FIXED "locinfo title">

Architectural forms could resolve many issues of ITS for two reasons. First, the mapping rules are separated by names, i.e. the names of the architectures. It is possible to have several rules, i.e. several architectures for one client dtd. This can be achieved by an additional processing instruction, e.g. ?IS10744:arch name="its-i18n-tool".... This architecture could map xhtml-plus-its.dtd to a format which is important for a specific i18n tool. [Lobin 2000] describes how a whole network of architectures can be used to create several interpretations of the same schemas. Second, the mappings can be used for validation of XML documents and their transformation respectively. Through a network of mappings, an XHTML document with ITS specific markup could be transformed into documents which are useful for specific processing steps.

These facilities of architectural forms resolve many issues of ITS which have been mentioned in section 3: the resolution of the issues 2 (information about the content of attribute), 3 (linking to external information), 4 (incompatibility with existing schemas), 5 (impact on the processing chain), 6 (conflict between existing markup and ITS markup) and 7 (versioning) can benefit from architectural forms. Unfortunately, architectural forms have not been successful for various reasons. The original syntax used for declaring architectural forms was based on SGML-features not available in XML. Probably, the most important reason for the non-success of architectural forms was the limited demand from the praxis. One reason for the definition of architectural forms was the provision of a special purpose, document grammar-driven document transformation mechanism. But for this purpose most users preferred XSLT, or even Perl. Consequently, software support for AFDR is rare.

An alternative for AFDR could be the introduction of an XML based format with similar functionality:

<its:purposeSpec>
 <servesPurpose origVoc="span" its="its-span"/>
</its:purposeSpec>

<element name="span-its">
 <dsrl:name-map>span</dsrl:name-map>
 <text/>
</element>

4.3.2 An RDF based approach

Architectural forms describe sets of rules of the form A maps to B. A is a markup construct in the client dtd, B is a markup construct in the meta dtd. This approach of schema annotation can be described as rule-based. Another approach, which will be described in this section, is knowledge-based. The approach has been described in detail by [Sasaki 2004]. It is based on work conducted within the research group Text-technological modeling of information, which is funded by the German Research Foundation. [Sasaki et al. (2003)], [Bayerl et al. 1999] and [Witt (2005)] provide further information.

In this approach, schemas and XML documents are an information resource which is named as primary information structuring. The knowledge-based schema annotation approach is conceived as a different level of information structuring, which is called secondary information structuring. The schemas and documents exist independently of secondary information structuring. The approach is called knowledge-based, because RDF [Resource Description Framework] [Manola and Miller 2004] is used to realize secondary information structuring. An example of these statements is given in Figure 9. It shows the description of a span in secondary information structuring, and the information in schemas and XML documents to which this description refers to.

Six RDF-statements are given. Each statement consists of a subject, e.g. sis:span, a predicate, e.g. s2p, and an object, e.g. element chunck { attribute type { 'span' }, text }. For readability, numbers are assigned to the statements. Statement [1] says that sis:span is an instance of the class Concept, which is defined in an RDF Schema [Brickley et al. 2004] for the development of secondary information structuring¹¹. That is, sis:span does not denote an element in a document or an element declaration in a schema, but an abstract unit which can be realized as markup - e.g. as an element span, as an element chunck with an attribute type="span", and so on. Also, sis:span is defined in secondary information structuring independently of a specific schema language. It can be realized in XML DTDs, RELAX NG, and so on.

The realization of sis:span is given in primary information structuring. Statements are used to describe the mapping of sis:span to one way of realization, i.e. the mapping from secondary information structuring to primary information structuring. The statements [2]-[5] describe mappings to element declarations within various schema languages. The mapping is realized with the predicate s2p. This predicate is also defined in the RDF Schema mentioned above. Examples of its usage are given for RELAX NG in its compact syntax [2], an XML Schema document [3], an XML-DTD [4], and a Schematron document [5]. Statement [6] provides a human readable comment about the meaning of sis:span.

Three things are to be mentioned: about the mechanism for selecting information in primary information structuring, what is being selected, and what other predicates except s2p are available in secondary information structuring.

First, the selection mechanism currently uses URI references¹² to select information encoded in XML based schema languages. Statements with the predicate s2p then refer to the unique identifier of an element in a schema. An example is an element with the ID spanDecl in an XML Schema, cf. statement [3]. Another way of selection is using the compact syntax of RELAX NG. The declaration is then given as the literal value in the object of the statement, see statement [2]. But it is also possible to use other selection mechanisms which are specific to a schema language. For example, [Holstege and Vedamuthu (2005)] define component designators as a format to identify components of an XML schema. They consist of an URI which identifies the schema itself, and a fragment part to specify the component path. The fragment part is an XPointer Scheme, cf. [Grosso et al. (2003)], that uses a schema component path. As an example, the following two statements could replace statement [3]. The first statement maps span to a globally defined declaration of a span element. The second statement selects a local declaration which is part of a named complex type paraType:

sis:span s2p http://www.mySchema2.xsd#(/~element::span)
sis:span s2p http://www.mySchema2.xsd#(/~type::paraType/model::choice/element::span)

Second, it is also possible to select information in XML documents. For this purpose a path language called caterpillar expressions which is defined by [Brüggemann-Klein and Wood (2000)] is being used¹³. For example, to identify all span elements which are child elements of a p element, the following statement can be used:

(sis:-span-in-para
      s2p "pathEx 'span' up 'p'".)

Third, other predicates and pre-defined constructs are available to make further statements in secondary information structuring. The following list introduces only a subset of these predicates.

• sis: the namespace prefix for concepts in secondary information structuring, for example sis:span. Currently, just a dummy-namespace is being used:
  http://example.com/sekStruk.
• subConceptOf: predicate for the creation of a conceptual hierarchy. For example (sis:span-in-para subConceptOf sis:span.) expresses that sis:span-in-para is sub ordinate to sis:span. If the concepts are mapped to markup with the predicate s2p, the relation is interpreted as a subset relation respectively. E.g., a span element inside a p element is a subset of all span elements.
• componentOf: predicate which is used to describe component relations between concepts. An example is (sis:locinfo componentOf sis:span.). This statement describes that a sis:locinfo concept is part of a sis:span concept. If the concepts are mapped to markup with the predicate s2p, the component relation holds for the markup declarations respectively. E.g., a declaration of a locinfo attribute might be a component of a declaration for a span element.
• equal: predicate for the description of relations between concepts in secondary information structuring, e.g. (sis:span equal sis:inline.). Mapped to markup, this is interpreted as an identity relation between the markup declarations respectively, e.g. a span element is equal to an inline element in general. sis:inline can be mapped to several elements with several statements using s2p, e.g. html:span or html:em.
• s2c: predicate for the mapping between secondary information structuring and another separate conceptual level. For example, (sis:para s2c "http://www.cogsci.princeton.edu/~wn/concept#104824115".) describes the mapping to the paragraph concept from the WordNet database [Fellbaum 1998]. Here, the RDF representation of WordNet developed by Sergey Melnik is being used, see
  http://www.semanticweb.org/library/.

[Sasaki 2004] describes various processes which could be applied to secondary information structuring. Conceptual queries could be used to retrieve markup independently of element and attribute names, making use of their conceptual description in secondary information structuring. A test whether markup really has the properties which are described in secondary information structuring could be used as a kind of conceptual validation for XML documents. And the statements with the predicate equal could be a base for the transformation of primary information structuring, i.e. of marked-up documents or schemas.

Compared to the rule-based approaches of schema annotation in section 4.3.1, this knowledge-based approach has three benefits. First, there is no direct interrelation of markup constructs, i.e. their description in secondary information structuring is separated from their realization in primary information structuring. This separation is useful e.g. for the description of relations between schemas, without the need to combine the rules with a given set of element and attribute names in the schemas. Second, secondary information structuring allows to apply inferences, e.g. concerning the properties of concepts which have the subClassOf relation. And third, a mapping to further knowledge bases is possible, e.g. to WordNet, terminological data bases etc. Again this mapping is separated from the markup itself.

With secondary information structuring, all the issues of ITS which where mentioned during the discussion of architectural forms in section 4.3.1 can be resolved as well. In addition, the inference mechanism of subConceptOf allows for the specification of inheritance features (issue 8). The disadvantage of secondary information structuring is that it is not part of a standardized format and so far there is no stable implementation available. Nevertheless, its knowledge-based characteristics could be an input for the development of such a format.