Editing XML schema (section)

== Schema authoring choices ==
The focus of the ''schema'' definition  is structure and some semantics of documents. However, schema design, just like design of databases, computer program, and other formal constructs, also involve many considerations of style, convention, and readability. Extensive discussions of schema design issues can be found in (for example) Maler (1995)<ref name="M95">{{ cite book
 | author = Eve Maler and Jeanne El Andaloussi
 | year = 1995
 | title = Developing SGML DTDs: From Text to Model to Markup
 | publisher = Prentice Hall PTR
 | isbn = 978-0133098815
}}</ref> and
DeRose (1997).<ref name="D97">
{{ cite book | author = DeRose, Steven.
 | title = The SGML FAQ Book: Understanding the Foundation of HTML and XML
 | year = 1997
 | publisher = Kluwer Academic Publishers
 | isbn = 978-0792399438
}}</ref>

;Consistency: One obvious consideration is that tags and attribute names should use consistent conventions. For example, it would be unusual to create a schema where some element names are [[camelCase]] but others use underscores to separate parts of names, or other conventions.

;Clear and mnemonic names: As in other formal languages, good choices of names can help understanding, even though the names per se have no formal significance. Naming the appropriate tag "chapter" rather than "tag37" is a help to the reader. At the same time, this brings in issues of the choice of natural language. A schema to be used for [[Irish Gaelic]] documents will probably use the same language for element and attribute names, since that will be the language common to editors and readers.

;''Tag'' vs ''attribute'' choice: Some information can "fit" readily in either an element or an attribute. Because attributes cannot contain elements in XML, this question only arises for components that have no further sub-structure that XML needs to be aware of (attributes do support multiple tokens, such as multiple IDREF values, which can be considered a slight exception). Attributes typically represent information associated with the entirety of the element on which they occur, while sub-elements introduce a new scope of their own.

;Text content: Some XML schemas, particularly ones that represent various kinds of [[documents]], ensure that all "text content" (roughly, any part that one would speak if reading the document aloud) occurs as text, and never in attributes. However, there are many edge cases where this does not hold: First, there are XML documents which do not involve "natural language" at all, or only minimally, such as for telemetry, creation of vector graphics or mathematical formulae, and so on. Second, information like stage directions in plays, verse numbers in Classical and Scriptural works, and correction or normalization of spelling in transcribed works, all pose issues of interpretation that schema designers for such genres must consider.

;Schema reuse: A new ''XML schema'' can be developed from scratch, or can reuse some fragments of other ''XML schemas''. All schema languages offer some tools (for example, <code>include</code> and modularization control over namespaces) and recommend reuse where practical. Various parts of the extensive and sophisticated [[Text Encoding Initiative]] schemas are also re-used in an extraordinary variety of other schemas.

;Semantic vs syntactic{{dubious|date=May 2015}}: Except for a RDF-related one, no ''schema language'' express formally semantic, only structure and data-types. Despite being the ideal, the inclusion of RDF assumptions is very poor and is not a recommendation in the ''schema development'' frameworks.