I'm mostly okay with this.
Regarding aboutType and valueType, I note
we
don't use camel-caps in any other DITA
attribute.
I'm unclear what an editing tool or
publishing
process should do about aboutType and
valueType.
We'd need to specify this more clearly before
we
can add this to the DITA language. Can you
elaborate
on the processing expectations for these
attributes
including comparing/constrasting with the
existing
type attribute?
paul
From: Erik Hennum [mailto:]
Sent: Tuesday, 2005 July 26 19:38
To: Paul
Grosso
Cc:
Subject: RE: [dita]
Groups - DITA 1.1 Issue # 9 (IssueNumber9.html) uploaded
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="javascript:void(0);"/>
</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
<!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
