Non-grammatical changes between PWD 2008-05-14 and CR 2008-06-30 1. MOVED to background document This specification satisfies all requirements in the [PWD Requirements] except those requiring creation and control of rendering metadata at the taxonomy level referred to in requirements 3.1, 3.3 and 3.20. It covers all the examples, and also provides features originally deemed out of scope, such as requirement 3.15 related to embedding of data in text. 2. CLARIFICATION of rule [To clarify that it is not the case that a valid Inline XBRL Document must always be sufficient to result in an XBRL-valid document.] < Inline XBRL Documents which results in one or more Target Documents < when transformed according to the mapping rules prescribed in this < specification. --- > Inline XBRL Documents which when comprising sufficient metadata > results in one or more Target Documents when transformed according to > the mapping rules prescribed in this specification. 3. CLARIFICATION of rule [To clarify that the no-DTS rule applies to Validating Conformant Processors.] < It should never be necessary for a processor to access the DTS of the < Target Document when carrying out the transformation. Whether it does < so will depend upon the design of the processor. --- > It should never be necessary for a Conformant Processor or a > Validating Conformant Processor to access the DTS of the Target > Document whilst processing. Whether it does so will depend upon the > design of the processor. 4. CHANGE of rule [To require all tuple content to include ix:order, thus removing the need for the validator to access the DTS.] < Where correct order of children is significant for satisfying the < tuple's content model, an ix:order is provided to enforce the correct < order. --- > The ordering of children in the Target Document is enforced through > the {tuple order} property. < child elements are {value set}, ordered in accordance with {tuple < order} (if present). --- > child elements are {tuple content}, ordered in accordance with {tuple > order}. 5. CHANGE of rule [To require all tuple content to include ix:order, thus removing the need for the validator to access the DTS. Also, to remove the requirement for sequential ordering of ix:order values. These changes also incorporate some re-factoring.] < Any ix:tuple, ix:nonNumeric, ix:nonFraction or ix:fraction which is < not the child of an ix:tuple and which does not have an ix:tupleRef < attribute MUST NOT have an ix:order attribute. < < If ordering is significant within a given tuple, the children of that < tuple MUST have an ix:order attribute. < < If any such element has an ix:order attribute then all its siblings and < all other elements which share the same ix:tupleRef attribute MUST also < have an ix:order attribute. < < The values of all the ix:order attributes amongst sibling elements or < elements with the same ix:tupleRef attribute MUST be unique values of < type positiveInteger. < < If the element has an ix:tupleID attribute there MUST be at least one < other ix:fraction, ix:nonFraction, ix:nonNumeric or ix:tuple element < in the Inline XBRL Document Set with a {tuple reference} property equal < to the {id} property of the ix:tuple. < < The {target} property of the ix:tuple element MUST be equal to the < {target} property of its children or, if the ix:tupleID attribute is < present, the {target} property of all elements for whom the {tuple < reference} property is the equal to the {id} property of the ix:tuple. --- > The {target} property of the ix:tuple element MUST be equal to the > {target} property of all elements in {tuple content}. > > All elements MUST have an ix:order attribute if and only if they are > members of {tuple content}. > > There MUST be at least one element in {tuple content}. > > The values of all the ix:order attributes amongst elements in {tuple > content} MUST be unique. < elements for whom the {tuple reference} property is the equal to the < {id} < property of the ix:tuple. --- > elements in {tuple content}. 6. MOVED to background document Appendix A Relationship to other specifications (non-normative) This specification uses [XBRL 2.1] and [XML]. By incorporating metadata within the body of an HTML document it carries out a similar task to [MathML] and [SVG], and to that envisaged by both [Microformats] and [HTML5]. Between these standards, however, there is a divergence of approach to the inline encapsulation of metadata. [MathML] and [SVG] both allow metadata to be incorporated as elements within the HTML document. This is the approach taken by this specification. [Microformats] and [HTML5], however, both require metadata to be incorporated as attributes to existing HTML elements. The vocabulary for [HTML5] is currently a working draft. Incorporating XBRL-based metadata within attribute values would add a further layer of complexity to the Inline XBRL Document and be more difficult to comprehend without adding any tangible benefits. The present approach depends upon web browsers continuing not to display XML elements that are not HTML, and this behaviour is very unlikely to change in the foreseeable future. The present specification provides a clear mechanism for encapsulating [XBRL 2.1] metadata within HTML documents, and is supported by a schema document which complies with [Modular XHTML]. The attribute-based alternative, in contrast, depends upon an approach which is still in flux, and likely to remain unstable for some time to come, and therefore should not be used for the present specification. 7. CHANGE of rule [Changed ix:order attribute from positiveInteger to decimal in order to align it with the XBRL 2.1 Specification.] < ix:order = positiveInteger --- > ix:order = decimal