Hi, Paul:
Good issues. I've embedded some responses.
Thanks,
Erik Hennum
"Paul Grosso" <> wrote on 07/12/2005 09:26:30 AM:
> > From: [mailto:]
> > Sent: Monday, 2005 July 11 18:38
> > To:
> > Subject: [dita] Groups - DITA 1.1 Issue # 9 (IssueNumber9.html)
> >
> > Here's the HTML output from the DITA note for the data
> > element (1.1 issue #9)
>
> I had a few thoughts/questions:
>
> 1. If the data element provides information about its parent,
> what is the point/meaning/use case for nesting data elements?
Here's an example of a potential book information structure
for the book map:
<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>
To create such structures in the DITA map through specialization,
we need a nestable element for values within the topicmeta
element. (The current demonstration specializes a topic body
to get the necessary structural depth, ignoring the semantic
mismatch and the inconvenience of requiring external data.)
It's a good question whether we need to distinguish subordinate
data elements that are part of a structure from subordinate data
elements that provide distinct metadata about the data. One
possibility would be to use a different element (subdata?) for
nested substructures. In practice, however, do we need to
maintain a rigorous distinction? What does that buy us? The
distinction between metadata and record data is often one of
typical use rather than a fundamental difference in kind. For
instance, if I use the sender value to filter email, does that
mean the sender value is metadata about the email note rather
than record data that's part of the email note?
Regarding the phrase, "the data is supplied for the container
element," the intent is to indicate that, if the data values
are metadata, they apply to the container and, if the data
values are record data, they are associated with the container.
Which probably boils down to useless restatement of standard
XML containment.
> 2. Since the data element provides information about another
> element, I wondered if it made sense to provide some kind
> of "idref-ish" attribute on the data element to allow one
> to point to the target element. But upon reflection, I'm
> not sure it does.
The proposed data element has an href attribute for cases where
the value is a referenced object (either managed within DITA or
external to DITA).
If a data element with an href contains other data elements, the
values would pertain to the referenced object. For instance:
<demonstrator>
<creator value="XYZ, Inc."/>
<access href=""http://www.xyz.com/demo/">
<login>guest</login>
<password>guest</password>
</access>
</demonstrator>
There is an ambiguity with content references (such as xref,
topicref, and link) whether the data applies to the referenced
target or to the referencing context. For instance, rights
information clearly applies to the referenced target -- you
can't copyright a context. By contrast, the maintainer of a
referencing context might be different from the maintainer of
a referenced target.
We could introduce a separate element, containable only
within content referencing elements, to disambiguate. I'd
incline toward leaving it up to specialized processing
that's sensitive to the semantics of the data.
> 3. I could imagine having similar metadata for multiple elements,
> and you might not want to repeat the same information again.
> Would the standard conref mechanism allow one to have a data
> element that could just refer to another data element?
Good point about reuse. The univ-atts attribute list includes
both id and conref attributes, so I think that (as luck has it,)
the existing attributes have the capability. The description
might point out to specializers the importance of preserving
both id and conref attributes to support reuse.
By the way, a recommended practice for specializers would be
to avoid using mixed content models because the data element
should supply values. That is, if a data element contains
subelements, you should use the value attribute instead of
text mixed with subelements. (An optimal grammar would allow
subelements or text but not both.) We could introduce a
separate element (datatext?) for textual content, but the benefit
of having only one generic data element in base content models
might outweigh the benefit of enforcing the recommended practice.
