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


I have the feeling that I'm missing something.
Sort of like when you're in a foreign country
where you (think you) speak the language, but
you get the sense that you aren't really
communicating.

I think there is way too much "in the dita model"
that is "hidden" in the processing.  I'm not
just saying that myself.  I've heard this from
others trying to work with dita.  I think it should
be the goal of this TC to try to codify as much as
possible about dita in the schema itself and avoid
"mushy application semantics" as much as possible.

Adding a data element with yet more "leave it to
the application" concerns me.

Let me try again below to address your email.

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

> > 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.
> 
> An excellent issue.  To rephrase:
> 
> *  Some containers (for instance, <organization>) have
>    identity and are the subject of subelement properties
>    ("a book can have an owning organization, which in 
>    turn can have a phone number").
> 
> *  Some containers (for instance, <bkrights>) seem to
>    provide organizing categories for the properties of
>    an ancestor ("some of the book's properties have to
>    do with rights, but a book doesn't have rights
>    that in turn have copyright years").
> 
> Is this distinction one of interpretation,

No.

> however, 
> rather than a hard and fast differences that we could 
> encode in the markup?

No.  Relationships among objects are exactly what
XML markup should be good at.

If you are going to define a bunch of elements that
provide meta-data (or properties or whatever you
want to call it) about other elements, you should
make it clear what the other elements are.

Containment is one way of doing that.  References
(such as idrefs) are another.  But one shouldn't
have to guess.

As far as only using containment, what do you do if
you want to provide metadata for an empty element?

> 
> For instance, if we added a property specifying the 
> locales in which a specified set of book rights are 
> valid, would that make us tend to think of <bkrights> 
> more as a subject of properties ("a book has rights 
> in the US and other rights in the EU") and less as 
> an organizing category?
> 
> For some properties, can the same property be considered
> to apply to any of several levels of ancestry (treating 
> the intervening levels of containment as categories that
> combine to label the full semantic of the property)?
> 
> For instance, does <phone> have a subject of <organization> 
> or of <bkowner>?  That is, does the organization have a
> phone number or does the book owner have an organization 
> phone number?  For that matter, can we treat a book as 
> having an owner contact phone number?
> 
> For another example, if an application regarded the stock 
> symbol as the only significant property of rights ownership, 
> could the application legitimately treat the stock symbol 
> as a property of the book (albeit with a long semantic label)?
> For instance, outputting a rights table in which the rows 
> are books and the columns consist of the copyright years 
> and the owner identifiers (stock symbols)?

You ask lots of questions, and I'm not sure to what purpose.
The answer to all of this is maybe yes, maybe no, but one
shouldn't have to guess, so we should give explicit answers
in the markup.

> 
> I'm coming around to the thought that default processing
> should treat every data property as having its container 
> as its subject 

That would be a fine semantic--it's deterministic--except
I thought all the discussion above indicated that it might
make sense to provide metadata that referred to other than
its immediate parent.

If we are going to go to the trouble to define a new element
that can be used as a specialization base to hold metadata,
I think we should provide a mechanism for it to point to 
the element that this metadata is about.

> (with the exception of data contained by the 
> <prolog> or <metadata> elements, which of course have the 
> topic as a whole as its subject).

By "contained by" do you mean only children or all
descendants?  I assume the former, since the latter
contradicts the containment idea you are proposing.

> 
> Applications that know the semantics of the data or that 
> have  access to a more formal definition of property 
> relationships outside of DITA (such as an RDF definition
> of transitivity up the containment hierarchy) are free to 
> interpret the subjects of properties accordingly.

Applications that really want to do so can always
ignore some information in the markup and interpret
anything any way they want.  That's not a good 
basis for determining ones data model.

> > > > 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.)
> 
> I misunderstood.  The thought for the href attribute is the 
> opposite -- not the subject of the property but the object.

I'm now guessing by object of the property you mean,
for example, the "value" of the property, correct?

That's fine, but orthogonal to my issue of how to
point to what you call the "subject".

> 
> I agree that we need conref,

I'm confused.  I didn't mention conref.  To what does
this refer?

> but I'd suggest that we also need 
> the ability to output values that are references.  For instance,
> 
> *  The identifier of the DITA topic that provides the full
>    explanation of the license for a product described in a book.
> 
> *  The book owner's website.
> 
> *  The ISBN for the companion volume expressed as a URI.

Are these just examples of why one might want the
value of a piece of metadata to be referenceable
via an href?

If so, I'm fine with that.  If not, I'm still lost.

> 
> > > If a data element with an href contains other data elements, the
> > > values would pertain to the referenced object.

Ooops, lost again.  I thought the href pointed to
the value of the metadata, but now you are saying
that the referenced object has metadata.  Also,
this seems to be contradicting the idea that
metadata always refers to its container.

> For instance:
> > > 
> > >     <demonstrator>
> > >         <creator value="XYZ, Inc."/>
> > >         <access href="http://www.xyz.com/demo/";>
> > >             <login>guest</login>
> > >             <password>guest</password>
> > >         </access>
> > >     </demonstrator>
> > 
> > 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)?

I'd still like to know what the above example means.

> 
> That paragraph should have had its own example.  Consider
> the following example where the maintainer element is a 
> specialized data element:
> 
>     <topicref href="sometopic.dita">
>         <topicmeta>
>             <maintainer>Sachiko</maintainer>
>         </topicmeta>
>         ...
>     </topicref>
> 
> Is Sachiko responsible for maintaining the references in this 
> branch of the map?  Or for maintaining the referenced content
> of sometopic.dita?  A default process would have a hard
> time harvesting the data without resolving that ambiguity.

I agree that default processes shouldn't have to guess
what is being referenced by some metadata.

> 
> So, the data element might need an attribute to disambiguate 
> these cases.  Something like 
> 
>     <!ATTLIST data reference (source|target) "source">
> 
> That way, a specialized element could assign a fixed or defaulted
> value to the reference attribute in the document type so the 
> ambiguity wouldn't arise in the instance.  

Lets give the data element an attribute that lets it point 
to the thing to which the metadata is about instead of just 
going halfway with reference={source|target}.

paul


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