dita — archive

modification to

From: Erik Hennum
To: [email protected]
Date: Mon, 27 Feb 2006 19:33:00 -0000

 MHonArc v2.5.0b2 -->
















dita message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: modification to <data> element proposal




From: Erik Hennum <[email protected]>
To: "DITA TC" <[email protected]>
Date: Mon, 27 Feb 2006 11:20:08 -0800







Hi, Esteemed DITA Technical Committee:


Regarding the <data> element proposal:


http://www.oasis-open.org/apps/org/workgroup/dita/download.php/14073/Issue9.html


Michael Priestley pointed out a design flaw to me.  While I am loathe to reopen an approved design, I also don't want to see us add a flawed design that will be much more difficult to fix later.


Here's the current design in DTD syntax:


<!ELEMENT data  (#PCDATA|%keyword;|%term;|%image;|%object;|%ph;|%data;)*>

<!ATTLIST data    %univ-atts;

                  name        CDATA #IMPLIED

                  label       CDATA #IMPLIED

                  typeid      CDATA #IMPLIED

                  abouthref   CDATA #IMPLIED

                  aboutformat CDATA #IMPLIED

                  abouttype   CDATA #IMPLIED

                  value       CDATA #IMPLIED

                  href        CDATA #IMPLIED

                  format      CDATA #IMPLIED

                  type        CDATA #IMPLIED

                  outputclass CDATA #IMPLIED

>


The problem has to do with identifying an optional data subject with the about* attributes.  It is potentially confusing to the writer to have a variant of the referencing attributes.  It's also potentially confusing to have a single element represent both subject and object.  Finally, it prevents the specializer from specializaing the data subject and object independently.


The fix is to provide separate elements for the data subject and data object.  While this approach has a downside of adding two elements to all <data> contexts instead of one, that downside is outweighed by the benefits listed above.


Here's the revised design in DTD syntax:


<!ELEMENT data-subject  ((%data;), (%data;|%data-subject;)*)>

<!ATTLIST data-subject  %univ-atts;

                  href        CDATA #IMPLIED

                  format      CDATA #IMPLIED

                  type        CDATA #IMPLIED

                  scope      (local | peer | external)        #IMPLIED

                  outputclass CDATA #IMPLIED

>

<!ELEMENT data  (#PCDATA|%keyword;|%term;|%image;|%object;|%ph;|%data-subject;|%data;)*>

<!ATTLIST data    %univ-atts;

                  name        CDATA #IMPLIED

                  label       CDATA #IMPLIED

                  datatype    CDATA #IMPLIED

                  value       CDATA #IMPLIED

                  href        CDATA #IMPLIED

                  format      CDATA #IMPLIED

                  type        CDATA #IMPLIED

                  scope      (local | peer | external)        #IMPLIED

                  outputclass CDATA #IMPLIED

>


For additional consistency or clarity, the modified design also:



Adds the scope attribute to both <data-subject> and <data>
Renames the typeid attribute to the datatype attribute


In the following example, <statisticsTable> is specialized from <data-subject> and <statisticsSource> from <data>:


<financialAnalysis id="ar-xyz">

<title>Analysis of XYZ Corporation</title>

<analysisProlog>

    <statisticsTable type="simpletable" href=""#ar-xyz/stats">

        <statisticsSource format="xbrl" href=""http://sec.gov/data?corp=xyz"/>

    </statisticsTable>

</analysisProlog>

<analysisBody>

    ...

    <simpletable id="stats">

        ...

    </simpletable>

    ...

</analysisBody>

</financialAnalysis>


For instance, after XYZ restates their earnings, a process might refresh the contents of the simpletable by rerunning the query.



What do you think?



Erik Hennum

[email protected]













[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]