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 <ehennum@us.ibm.com>
- To: "DITA TC" <dita@lists.oasis-open.org>
- Date: Mon, 27 Feb 2006 11:20:08 -0800
Hi, Esteemed DITA Technical Committee:
Regarding the <data> element proposal:
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
ehennum@us.ibm.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]