[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Groups - DITA 1.1 Issue # 9 (IssueNumber9.html) uploaded
"Paul Grosso"
<pgrosso@arbortext.com>
07/27/2005 09:42 AM |
|
Hi, Paul and Committee:
Let's follow the RDF/A proposal and add an optional about attribute:
http://www.w3.org/MarkUp/2004/rdf-a
The rule for determining the subject of the <data> property:
* If you supply a URI (or key reference) in the about attribute, the subject
of the property is the identified target.
* If you omit the about attribute, the default subject is the parent element
with the following exceptions for consistency with existing attribution
of metadata elements:
o If the parent element is <prolog> or <metadata>, the default
subject of the property is the topic.
o If the parent element is <topicmeta>, the default subject of the
property is the grandparent if the grandparent doesn't have an href element.
If the grandparent does have an href element (ie, a reference), the subject
of the property is the target of the reference. (That's the long way of
saying that the metadata applies to the target of a <topicref> or
<navref> element.)
I see clear value for the about attribute where content is generated by
an automated process or where the subject can vary from instance to instance.
I have a harder time seeing the value where the content is authored and
the subject should always be an element with the same containment relationship.
The author has to identify the subject correctly in every document instance,
which seems burdensome and error prone. To minimize the errors, we should
probably have an aboutType attribute that can specify the type for the
target of the about attribute. That way, the designer of a specialized
<data> element can constrain the valid subject for the about attribute.
In the following example (where <bkrights> and everything it contains
are specialized from the <data> element), we have the phone of the
owner of the book:
<bookmap id="xguide">
<bkrights>
<bkcopyrfirst><year>2003</year></bkcopyrfirst>
<bkcopyrlast><year>2005</year></bkcopyrlast>
<bkowner id="xguideOwner"
about="#xguide">
<organization>
<orgname>XYZ,
Inc</orgname>
<phone
about="#xguideOwner">123-456-7890</phone>
<resource
href=""http://www.xyz.com/"/>
</organization>
</bkowner>
</bkrights>
...
</bookmap>
In the following alternative, we have the phone of the organization of
the owner of the rights of the book:
<bookmap>
<bkrights>
<bkcopyrfirst><year>2003</year></bkcopyrfirst>
<bkcopyrlast><year>2005</year></bkcopyrlast>
<bkowner>
<organization>
<orgname>XYZ,
Inc</orgname>
<phone>123-456-7890</phone>
<resource
href=""http://www.xyz.com/"/>
</organization>
</bkowner>
</bkrights>
...
</bookmap>
In the following example (where <maintainer> is specialized from
<data>), we have the maintainer of the topic:
<topicref href=""sometopic.dita">
<topicmeta>
<maintainer>Sachiko</maintainer>
</topicmeta>
...
</topicref>
In the following example, we have the maintainer of the position in the
map:
<topicref id="thisbranch" href=""sometopic.dita">
<topicmeta>
<maintainer about="#thisbranch">Sachiko</maintainer>
</topicmeta>
...
</topicref>
In passing, the downside here is that we have no way to simplify the author's
life by creating a specialized element that always applies data to the
map position instead of the referenced topic. We can set the aboutType
to constrain the subject to topicref elements.
Here are some examples of potential uses for a specialized <data>
element within the topic content.
In the following example (where the <sourceFile>, <startDelimiter>,
and <endDelimiter> elements are specialized from <data> but
the <codeFragment> is specialized from <pre>), we have a start
delimiter for a code fragment. (Perhaps it is refreshed automatically.)
<example>
<title>An important coding technique</title>
<codeFragment>
<sourceFile value="helloWorld.java"/>
<startDelimiter value="FRAGMENT_START_1"/>
<endDelimiter value="FRAGMENT_END_1"/>
...
</codeFragment>
</example>
In the following example (where the <realEstateProperty> and everything
it contains are specialized from <data> but <houseDescription>
is specialized from <section>), we have a real estate block for a
real estate property for a house description:
<houseDescription>
<title>A great home for sale</title>
<p>This elegant....</p>
<realEstateProperty>
<realEstateBlock value="B7"/>
<realEstateLot value="4003"/>
...
</realEstateProperty>
<object data=""B7_4003_tour360Degrees.swf"/>
</houseDescription>
Other possible specializations include the core components of UBL.
Will that fly? I've appended the tally of attributes (by my count).
Thanks for working through the issues,
Erik Hennum
ehennum@us.ibm.com
<!ELEMENT data (#PCDATA|%keyword;|%term;|%image;|%object;|%ph;|%data;)*>
<!ATTLIST data %univ-atts;
name CDATA #IMPLIED
label CDATA #IMPLIED
typeid CDATA #IMPLIED
about CDATA #IMPLIED
aboutType CDATA #IMPLIED
value CDATA #IMPLIED
href CDATA #IMPLIED
keyref CDATA #IMPLIED
valueType CDATA #IMPLIED
outputclass CDATA #IMPLIED
>
name = authored name of the type (typically, the same as the specialized
element name)
label = display label for the type
typeid = full machine-processable identifier for the type
about = reference to a DITA element or non-DITA resource that's the subject
of the data
aboutType = element constraint on the subject
value = literal data value
href = "referenced" data value that's either a DITA element or non-DITA resource
keyref = key referenced data value
valueType = constraint on the value, href, or keyref
ouputclass = weak semantic assertion about the instance
A <data> element can have only one of the value, href, or keyref
attributes (or none of the three).
The rest of the proposal:
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/13539/IssueNumber9.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]