Our current work can be downloaded from MicroFormats. Our summary of the issues that have arisen from this work follows:

Assumptions

1. That XHTML validity is not required

Our chosen approach embeds the metadata within the HTML using custom attributes and non-HTML tags. This results in invalid XHTML. The alternative approach (the "microformats" method) is very much more verbose and makes it less easy to extract the XBRL.

We believe that XHTML validity is not important, because browsers are almost invariably designed to cope with HTML which is not even well-formed, and that ease of processing, and simplicity, are much more significant. The approach we are taking, of using custom attributes and tags, already has a precedent - embedded SVG.

2. That it must be possible to round-trip the data

Renderings of XBRL instance documents are not always required to display all the data held in the underlying document. For instance, the XBRL instance document may include static data which is by convention not displayed: 

<ae:CompanyNotDormant contextRef='y2003'>true</ae:CompanyNotDormant>

We have assumed that such data must be included in the XHTML document, but with instructions to the browser that it should not be displayed. For instance: 

<span style="display:none;" tag:name="ae:CompanyNotDormant" tag:contextRef="y2003">true</span>

Unless this is assumed, we cannot ensure that the XBRL instance document is the same as that which would have been created by the originator of the data.

3. That DTS discovery is not required for extraction of the instance data

It is highly preferable that it should be possible to generate the XBRL instance, from the XHTML document, without having to refer to the DTS.

4. The use of Micro-XBRL markup should be processor-independent

For convenience, we have developed a style-sheet written in XSLT v2.0. We expect that real-world applications may be developed in a number of languages, including XSLT v1.0, Java, and JavaScript.

Design decisions

1. Unconventional handling of tuples in the current stylesheet

One particular problem with tuples is making sure they are grouped correctly at the extraction stage. For example, the following fragment from an instance conforming to the UK GAAP taxonomy: 

<pt:EquityAuthorisedDetails>
  <pt:TypeOrdinaryShare contextRef='y2003'>A shares</pt:TypeOrdinaryShare>
  <pt:NumberOrdinarySharesAuthorised precision='INF' contextRef='e2003' unitRef='shares'>1000</pt:NumberOrdinarySharesAuthorised>
  <pt:ParValueOrdinaryShare precision='INF' contextRef='y2003' unitRef='GBP'>1</pt:ParValueOrdinaryShare>
  <pt:ValueOrdinarySharesAuthorised precision='INF' contextRef='e2003' unitRef='GBP'>1000</pt:ValueOrdinarySharesAuthorised>
  <pt:ValueOrdinarySharesAuthorised precision='INF' contextRef='e2002' unitRef='GBP'>1000</pt:ValueOrdinarySharesAuthorised>
</pt:EquityAuthorisedDetails>

could be output as: 

<pt:EquityAuthorisedDetails>
  <pt:TypeOrdinaryShare contextRef='y2003'>A shares</pt:TypeOrdinaryShare>
  <pt:NumberOrdinarySharesAuthorised precision='INF' contextRef='e2003' unitRef='shares'>1000</pt:NumberOrdinarySharesAuthorised>
  <pt:ParValueOrdinaryShare precision='INF' contextRef='y2003' unitRef='GBP'>1</pt:ParValueOrdinaryShare>
  <pt:ValueOrdinarySharesAuthorised precision='INF' contextRef='e2003' unitRef='GBP'>1000</pt:ValueOrdinarySharesAuthorised>
</pt:EquityAuthorisedDetails>

<pt:EquityAuthorisedDetails>
  <pt:TypeOrdinaryShare contextRef='y2003'>A shares</pt:TypeOrdinaryShare>
  <pt:NumberOrdinarySharesAuthorised precision='INF' contextRef='e2003' unitRef='shares'>1000</pt:NumberOrdinarySharesAuthorised>
  <pt:ParValueOrdinaryShare precision='INF' contextRef='y2003' unitRef='GBP'>1</pt:ParValueOrdinaryShare>
  <pt:ValueOrdinarySharesAuthorised precision='INF' contextRef='e2002' unitRef='GBP'>1000</pt:ValueOrdinarySharesAuthorised>
  </pt:EquityAuthorisedDetails>

We have temporarily resolved this by using table element around the tuple elements that are to be grouped. Thus: 

table width="100%">
        <tr tag:name="pt:EquityAuthorisedDetails">
        <td style="display:none;" tag:name="pt:TypeOrdinaryShare" tag:contextRef='y2003'>A shares</td>
        <td style="display:none;" tag:name="pt:NumberOrdinarySharesAuthorised" tag:precision='INF' tag:contextRef='e2003' tag:unitRef='shares'>1000</td>
        <td style="display:none;" tag:name="pt:ParValueOrdinaryShare" tag:precision='INF' tag:contextRef='y2003' tag:unitRef='GBP'>1</td>
        <td class="rightalign" style="width:50%;" tag:name="pt:ValueOrdinarySharesAuthorised" tag:contextRef='e2003' tag:unitRef='GBP' tag:precision='INF' tag:scale="1">1,000</td>
        <td class="rightalign" style="width:50%;" tag:name="pt:ValueOrdinarySharesAuthorised" tag:contextRef='e2002' tag:unitRef='GBP' tag:precision='INF' tag:scale="1">1,000</td>
        </tr>
        </table>

However, this solution will not work with all possible table and tuple constructions. The longer term solution to this problem is to use idrefs.

Open issues

[Moved to IWD]

Regarding the inline XBRL approach's stylesheet transformation to XBRL, in addition to open issues already identified: