I'm not finding the keyref attribute anywhere
in
http://docs.oasis-open.org/dita/v1.0/langspec/ditaref-type.toc.html
If it's being added in 1.1, where can I find
the
writeup on it?
I can't answer your first question yet. I know
href
doesn't do what I want, but I don't know how
keyref
does what Erik's about attribute was going to
do.
paul
From: Michael Priestley
[mailto:]
Sent: Wednesday, 2005 July 27
8:59
To: Paul Grosso
Cc:
Subject: RE: [dita] Groups - DITA 1.1
Issue # 9 (IssueNumber9.html) uploaded
1) Could we get rid of "about" and
"aboutType" if we just say that the href/keyref attributes already provide
equivalent functionality? IE, if the data element references other content,
then the data element is about that content; otherwise the data element is
about the parent element.
2) With
regards to providing href: there are a set of attributes that typically come
along with href, including scope, format, and type. It looks like you've got
valueType below acting as equivalent to the existing type attribute - for
consistency's sake I think we should either keep it the same, or split off
type so that valueType applies to value and type applies to href.
3) how is typeID different from "id"?
(which is already there courtesy of univ-atts)
Michael Priestley
"Paul Grosso"
<>
07/27/2005 09:42 AM
To
<>
cc
Subject
RE: [dita] Groups -
DITA 1.1 Issue # 9 (IssueNumber9.html)
uploaded
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
