Using a default namespace improves readability.] [ Rationale: Namespace-freeĭocuments are obsolete every set of names should be in some When extending pre-existing document types that do not use namespaces.Ī default namespace SHOULD be used. Element names MUST be in a namespace, except.DTDs and/or W3C XML Schemas MAY be provided for compatibility with existing products, tools, or users.Regular expressions SHOULD be provided to assist in validating complex values.The "Venetian Blind" style (one rule per element type) is unsuited to RELAX NG and SHOULD NOT be used. Schemas MAY use the "Russian Doll" style (schema resembles document) if they are short and simple. Schemas SHOULD use the "Salami Slice" style (one rule per element).Schematron handles arbitrary cross-element and Learn, and can be converted one-to-one to and from the XML syntax when
The compact syntax is quite easy to read and RELAX NG is the most flexible schema language, with very few arbitrary Embedded Schematron rules MAY be added to the schema for additional fine control. The schema language SHOULD be RELAX NG compact syntax.Document formats SHOULD be expressed using a schema language.When extending formats, use the implicit style of the existing format, even if it contradicts this guide.As a last resort when an element or attribute is required by the format but is not appropriate for your use case, use someįixed string as its value. Might be used in creative ways if the vanilla semantics aren't Don't completely repurpose them, but do try to see how they Use of the prescribed elements and attributes, especially any that are If you are reusing or extending an existing format, make sensible.Try to get wide review of your format, from outside your organization as well, if possible. Creating an entirely new format should be done only with care and consideration read Tim Bray's warnings first. Attempt to reuse existing XML formats whenever possible, especially those which allow extensions.To design or not to design, that is the question The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in this document in the sense of RFC 2119.ġ. They are maintained in the same document in hopes that they won't get out of date, but they are not considered normative. It also does not affect XML document formats that are created by translations from proto buffers or through some other type of format.īrief rationales have been added to most of the guidelines. A document that includes embedded content in XHTML or some other rich-text format, but also contains purely machine-interpretable portions, SHOULD follow this style guide for the machine-interpretable portions. Its rules are not applicable to formats such as XHTML (which should be formatted as much like HTML as possible) or ODF which are meant to express rich text. This guide is meant for the design of XML that is to be generated and consumed by machines rather than human beings. When participating in the creation of public or private document format designs, the guidelines may be helpful but should not control the group consensus. These guidelines apply to new designs, and are not intended to force retroactive changes in existing designs. Document formats usually include both formal parts (DTDs, schemas) and parts expressed in normative English prose. IntroductionThis document provides a set of guidelines for general use when designing new XML document formats (and to some extent XML documents as well see Section 11).
0 kommentar(er)
