The Rendering Working Group circulated three PWDs of the Specification for
Inline XBRL and received a substantial amount of feedback, all of which
was documented and responded to.  

Full details are provided in accompanying documentation which has been extracted from 
the Working Group's wiki area.

This documentation is in the files feedback-PWD-1.html and feedback-PWD-3.html

The folllowing summary lists the feedback:

1. [David Forbes] Inline XBRL does not allow round-tripping of data. 

   Inline XBRL is not designed to round-trip the data. 

2. [David Forbes] How does Inline XBRL handle multiple occurrences of a 
   concept ? 

   By putting the duplicate concepts into ix:hidden. 

3. [David Forbes] How will accounts packages handle mapping for Inline 
   XBRL ? 

   Inline XBRL will not simplify the mapping process for accounting 
   applications. 

4. [David Forbes] Finance Directors prefer to create PDFs instead of 
   Inline XBRL. 

   This is a matter for individual regulatory authorities. 

5. [David Forbes] The ix:hidden element might be abused. 

   Individual regulatory authorities will impose their own restrictions 
   on the use of ix:hidden. 

6. [Olivier Servais] Use of namespace prefixes in ix:name attributes. 

   Use of namespace prefixes will be enforced at Schema level. 

7. [Olivier Servais] Does Inline XBRL support dimensional contexts ? 

   Yes. 

8. [Ian Stokes-Rees] Why not put ix:header into the head element ? 

   Because not all browsers will include that in their DOM view. 

9. [Geoff Shuetrim] Can context values be tied to displayed text ? 

   It was considered that this would make the specification too 
   complicated. 

10. [Geoff Shuetrim] What is the relationship of the spec to HTML and 
    XHTML ? 

    The specification is written with both in mind although we have an 
    XML Schema implemented only for XHTML. 

11. [Geoff Shuetrim] Can the spec be expanded to cover non-HTML 
    vocabularies ? 

    In theory yes, but the spec has been restricted to the present 
    use cases. 

12. [Geoff Shuetrim] Why do we need Inline XBRL ? 

    To allow preparers to define a pretty-much exact rendering. 

13. [Geoff Shuetrim] Can we be certain that the XBRL content matches 
    the display ? 

    We believe that automated testing will allow recipients to be 
    reasonably confident of this. 

14. [Dave Raggett] Inline XBRL should only use existing HTML attributes. 

    This approach was previously considered by the WG and was 
    rejected as being less suitable. 

15. [Dave Raggett] The XHTML-XBRL schema module may not work with 
    many browsers. 

    The schema is designed primarily to allow enterprise processing 
    to be undertaken with confidence. 

16. [Holger Obst] How does Inline XBRL handle date transformations ? 

    Using Transformation Rules. 

17. [Holger Obst] Will Transformation Rules handle all character sets ? 

    Yes.