OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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

Erik Hennum had written:
> "Paul Grosso" <pgrosso@arbortext.com> wrote on 07/12/2005 09:26:30 AM:
> > > From: ehennum@us.ibm.com [mailto:ehennum@us.ibm.com] 
> > > Sent: Monday, 2005 July 11 18:38
> > > To: dita@lists.oasis-open.org
> > > 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>

It may not be obvious to all which of the above you meant
to be specializations of <data>.  I'm guessing it's all
the bk* elements and none others, is that correct?

I gather that bkrights is a child of bookmap, is that correct?

If so, then I assume bkrights is metadata about the bookmap element.
I could imagine the bkcopyr* elements are metadata about
the bkrights element, but is bkowner metadata about the 
bookmap element or about the bkrights element? 

What if I gave the bkowner element a <data> child that
included metadata about the incorporation status (stock
symbol, state of incorporation, etc.) of the bkowner?
Or maybe this data element would more appropriately be
a child of <orgname>.  In any case, I can see times I
want the data element to be referring to its parent and
other times when it should be referring to the parent of
its outermost ancestral element that is a specialization
of data: (ancestor::*[@class=" ...data..."])[1]::parent 
in xpath-ese.

> 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.

Actually, I'm afraid I don't understand the sentence above
about what the intent is.

> > 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).

I'm getting lost.  The value of what here?  The value of
the metadata within the data element?  If so, then that
sounds more like a kind of conref where you are referencing
the metadata.

My point #2 here was about the possibility of allowing the
data element to have an explicit pointer to the element for
which the data element's content was metadata--to address
the point discussed in #1 that you might not always want the
data element's metadata to be just about its parent. 

(Given the example below, maybe that is what you mean here,
I'm not sure.)

> 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>

Lost again.  Which elements are specializations of the data
element here?

Given "a data element with an href contains other data elements",
I assume all of access, login, and password are data elements,
is that correct?

So by "values would pertain to the referenced object" do you
mean that the login and password values are metadata about
"http://www.xyz.com/demo/"; and not metadata about <access>
or <demonstrator> or the parent of <demonstrator> (if
demonstrator is a data element)?

> > 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. 

I (think I) understand this point and agree, so no issue here.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]