[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-busdocs] RE: Adjectives vs nouns
Bruce's question is one I also asked myself while designing the abstract
[directive] (now [advisory]) info-type.
At the heart of the [advisory] info-type is a <rule> element, from which can
be specialized different types of rules: principles, exceptions, conditions,
exclusions, laws, clauses, stipulations, and so on. A <policy> info-type
specialized from the [advisory] abstract info-type could have at its heart
something like <benefit> | <condition> | <exclusion>, all specialized from
<rule>.
But what should <rule> be specialized from in the base <topic> info-type:
<abstract> or <shortdesc>?
Being by orientation and practice a pretty strict minimalist, I think it
should be <shortdesc> only. This encourages authors to keep the <rule>-type
content short and to the point. They still have the <body>-type content to
provide the reasons (and other related content) for the rule. Restricting
the <rule>-type elements to <shortdesc> content also encourages greater
modularity and promotes re-use of <rule>-type content in multiple contexts.
(You can see I've done a complete 180 on my original objections to the use
of the <shortdesc> element. ;-) )
But I know there will be pressure from users to have more flexibility in how
they define rules: the ability to have more than one paragraph element in
the <rule>-type element, for example, or to have images in the content, both
of which they can only do if the <rule> is specialized from the <abstract>
element.
Tim.
-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
Sent: Tuesday, April 13, 2010 11:03 AM
To: Hanna, Rob
Cc: dita-busdocs@lists.oasis-open.org
Subject: [dita-busdocs] RE: Adjectives vs nouns
From the example, the record type is for all sorts of records, and the names
'temporal' and 'event' are alike too narrow. (The activity of making the
record is an event, but such event information is metadata about the content
of the record itself. Likewise, the activity is an event when someone
measures attributes such as height and weight on different occasions, but
the record is not a record of that event.)
> Please note: neither of my sons were harmed in the making of these
examples.
Thanks, glad to know! And this nicely illustrates the point.
> The record abstract type is, in my estimation, a key information type
> used in business communication (and not typically in technical
> publications). It would be specialized to accommodate any record such
> as a test result, a incident report, a trip report, minutes, etc.
> Without an abstract type, we could shovel this type of information
> somewhere else, but I don't think it would fit as elegantly. My
> opinion is that this information type is unique in its behavior and
> relationship to other types of information.
Clearly, it should be a specialized document type. The question is, from
what should it be specialized? Should it be a document type specialised from
the abstract <description> type, or should it be a document type specialized
from a virtually identical abstract type? All the abstract types being
specialized from the even more abstract <topic> type that is in DITA now.
/Bruce
> -----Original Message-----
> From: Hanna, Rob [mailto:Rob.Hanna@wolterskluwer.com]
> Sent: Tuesday, April 13, 2010 8:52 AM
> To: Bruce Nevin (bnevin); tgrantham@timgrantham.com;
> rockley@rockley.com
> Cc: manning@rockley.com; zrendon@ptc.com; Bruce Nevin; Hanna, Rob
> Subject: RE: Adjectives vs nouns
>
> Good day, Bruce.
>
> Thank you so much for your thorough explanations and well-constructed
> arguments.
>
> One of the major distinctions for the record-type information is that
> unlike the other types of information, this information is essentially
> static. A description of something or someone will change as that
> thing or person changes.
>
> For example, today my son is 11 years old and 5' 7". In three years,
> my son will be 14 years old and 6' 9". The same piece of content will
> be used to describe my son except that it will be a different version
> of that same content - a version of the content from when my son was
> 11 wouldn't normally co-exist with a version from when my son was 14.
> While I have used a date to illustrate my point, no date is necessary
> to describe my son - the assumption is that the description is
> accurate as of the date of publication and is in present-tense.
>
> A record is different in that only one accepted version of the record
> would normally ever exist. The record may go through a number of
> iterations to get to version 1.0 but you wouldn't normally ever see a
> version 2.0 of the record.
>
> For example, on June 14 2009, my son fell off his bike requiring
> stitches on his left knee. On October 17 2009, my son fell of a
> playground slide requiring a partial cast on his right arm. These are
> both two separate records each with a required date stamp. I won't
> ever revise either record except to make corrections as may be
> necessary.
> Both records would co-exist within the same space and would be
> aggregated to form a medical history for my son. Please
> note: neither of my sons were harmed in the making of these examples.
>
> The record abstract type is, in my estimation, a key information type
> used in business communication (and not typically in technical
> publications). It would be specialized to accommodate any record such
> as a test result, a incident report, a trip report, minutes, etc.
> Without an abstract type, we could shovel this type of information
> somewhere else, but I don't think it would fit as elegantly. My
> opinion is that this information type is unique in its behavior and
> relationship to other types of information.
>
> > So we'd have to specialize children of <abstract>.
> And that means we need the parent <abstract> (or a specialization of
> it) as a container element for <summary>, <stamp>, <date-time>,
> <location>, and <occurrence>.
>
> This should in fact be a specialization of <abstract>.
>
> > On the other hand, why do we want to eliminate <abstract> from
> [descriptive]? I have often found that users want to say more before
> the body than properly will fit in <shortdesc>.
>
> I don't think that we should remove abstract from descriptive. The
> pseudo code example in the paper is not meant to be complete in anyway
> - just illustrative of the concept.
>
> I hope this makes sense.
>
> Cheers,
> Rob Hanna
>
>
> -----Original Message-----
> From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> Sent: Monday, April 12, 2010 5:48 PM
> To: tgrantham@timgrantham.com; Hanna, Rob; rockley@rockley.com
> Cc: manning@rockley.com; zrendon@ptc.com; Bruce Nevin
> Subject: RE: Adjectives vs nouns
>
> Whatever we decide, it will suggest henceforth to users the boundaries
> of the range of content types that they might specialize from it in
> the future.
>
> That's why I asked if it concerns records only of events or
> transactions, or if it includes other kinds of records. As presently
> defined, it's strictly temporal. Here's the given
> definition:
>
> Information that reports on an event.
> Records specific time and/or place of
> the occurrence and summarizes the outcome.
>
> Thinking of other types of records such as vital statistics or medical
> records, I realized that such records might be thought of as instances
> of the <reference> type (which is modeled under the [descriptive]
> abstract type, even though it's currently specialized from <topic>).
> (I hope my ad hoc use of square braces for abstract types here is
> clear.
> Obviously, not good as an ongoing convention.)
>
> A pertinent question, then, is: what distinguishes this
> [temporal/archival/transactional] type from the more general
> [descriptive] type? And do we really need that distinction?
> Could the <event> type be specialized from the [descriptive] abstract
> type? If not, why not?
>
> Every distinction we make must be able to stand up to this kind of
> question. What is its justification? By clarifying the distinctions we
> will be more clear about the various criteria that users must apply
> before specializing new document type X from this abstract type rather
> than from that one.
>
> Another question: is it likely to serve as the specialization ancestor
> of a useful family of document types? Now on this one I'm having some
> trouble imagining anything specialized from it except a record of an
> event. Is that sufficient justification for an entire abstract type as
> a basis for specialization?
>
> A third question concerns semantic distinction in the definitions. How
> distinct are the definitions of the [temporal/archival/transactional]
> type, quoted above, and the [descriptive] type? The [descriptive]
> abstract type has the following definition:
>
> Describes specific information about an object.
> It may describe characteristics of an object,
> a person, or a place. ...
>
> This could easily encompass both definitions, something like:
>
> Describes specific information about something.
> It may describe characteristics of an object,
> a person, a place, or an event. ...
>
> The more detailed definition ("reports on an event. Records specific
> time and/or place of the occurrence and summarizes the outcome.")
> applies to the <event> or <record> document type specialized from it.
>
> Indeed, what difference is there between the abstract type and the
> specialized element? It seems to me that the specialized element
> accounts for the entire range of semantics of the proposed abstract
> type, with nothing left over for specializing other sibling elements.
> So that's a negative answer to our third question. A 'family' of one
> specialized element makes the abstract type of limited usefulness.
>
> A fourth question concerns their structural similarity.
> Comparing their proposed structures, the [descriptive] type has only
> <shortdesc> before the body element; but instead of <shortdesc>, the
> [temporal/archival/transactional] type has a series of specialized
> elements: <summary>, <stamp>, <date-time>, <location>, and
> <occurrence>.
> The body is identical, except that [descriptive] includes a
> <characteristics> element at the end. Here are the two models as given
> in pseudocode:
>
> <descriptive>
> <title>
> <shortdesc>
> <descbody>
> <detail>
> <sublist>
> <characteristics>
> <related-links>
>
> <temporal>
> <title>
> <summary>
> <stamp>
> <date-time>
> <location>
> <occurrence>
> <temporalbody>
> <details>
> <sublist>
> <related-links>
>
> What is the specialization ancestor of these pre-body elements
> <summary>, <stamp>, <date-time>, <location>, and <occurrence>? Here's
> the content model of <topic>:
>
> <topic>
> <title>
> <titlealts>?
> (<shortdesc> | <abstract>)?
> <prolog>?
> <body>?
> <related-links>?
>
> Superficially, these new elements look like the children of <prolog>,
> but we can't go there because we're talking about content, not
> metadata about the content. So we'd have to specialize children of
> <abstract>.
> And that means we need the parent <abstract> (or a specialization of
> it) as a container element for <summary>, <stamp>, <date-time>,
> <location>, and <occurrence>. Or am I misunderstanding something basic
> about specialization? That's always possible. It wouldn't be the first
> time I had displayed ignorance for all to see.
>
> On the other hand, why do we want to eliminate <abstract> from
> [descriptive]? I have often found that users want to say more before
> the body than properly will fit in <shortdesc>.
> If we retain the (<shortdesc> | <abstract>)? choice as in <topic> then
> the children of <abstract> are available to specialize as <summary>,
> <stamp>, <date-time>, <location>, and <occurrence>. And if we do that,
> there is no structural reason for a separate abstract type, the
> <event> element can happily be a specialization of [descriptive].
>
> I find myself concluding that the main reason we are having so much
> trouble coming up with a good name for this abstract type is because
> we don't need it and shouldn't posit it.
>
> /Bruce
>
>
> > -----Original Message-----
> > From: Tim Grantham [mailto:tgrantham@timgrantham.com]
> > Sent: Monday, April 12, 2010 3:48 PM
> > To: 'Hanna, Rob'; Bruce Nevin (bnevin); rockley@rockley.com
> > Cc: manning@rockley.com; zrendon@ptc.com
> > Subject: RE: Adjectives vs nouns
> >
> > I favour "transactional" or "archival".
> >
> > How about "transcriptive"?
> >
> > Tim.
> >
> > -----Original Message-----
> > From: Hanna, Rob [mailto:Rob.Hanna@wolterskluwer.com]
> > Sent: Monday, April 12, 2010 3:37 PM
> > To: Bruce Nevin (bnevin); rockley@rockley.com
> > Cc: manning@rockley.com; tgrantham@timgrantham.com;
> zrendon@ptc.com;
> > Hanna, Rob
> > Subject: RE: Adjectives vs nouns
> >
> > I completely agree with Bruce. We aren't suggesting that we
> don't need
> > explanatory, descriptive, and procedural - we are simply
> acknowledging
> > that we can achieve what we are working towards using concept,
> > reference, and task until such time as the TC can render
> judgment on
> > the underlying abstract layer.
> >
> > How about:
> >
> > Event-based Information. Or
> > Record-based Information?
> >
> > I'm still favouring Transactional Information.
> >
> > Cheers,
> > Rob Hanna
> >
> > -----Original Message-----
> > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> > Sent: Monday, April 12, 2010 1:10 PM
> > To: rockley@rockley.com
> > Cc: manning@rockley.com; Hanna, Rob; tgrantham@timgrantham.com;
> > zrendon@ptc.com; Bruce Nevin (bnevin)
> > Subject: RE: Adjectives vs nouns
> >
> > The reason for adjectival names was to help distinguish the
> abstract
> > layer from the specific types specialized from it. I think that
> > criterion still applies.
> >
> > It's a little confusing to say we're going to *continue*
> with concept,
> > task, and reference. Rather, they're not going away any
> time soon, so
> > we're working around them. That's not a motivation for
> using nouns as
> > labels in the abstract layer.
> > Rather, it's even more important to emphasize that the
> existing base
> > types are of a different order from the abstract layer.
> >
> > Rather than saying we're going to continue with the
> <concept>, <task>,
> > and <reference> types, we acknowledge that they necessarily
> persist as
> > specializations of <topic> until the TC implements the
> abstract layer
> > as part of the standard--which of course they might never
> do, but we
> > hope they will. These current base types have an uncomfortable
> > relationship to our proposed specialization framework.
> > Hierarchically, they are on the same level as the abstract types,
> > since they are immediately specialized from <topic>, but there is a
> > place reserved for them to be specialized from <explanatory>,
> > <descriptive>, and <procedural> in the abstract layer.
> >
> > They aren't entirely incommensurate, but to share content
> one has to
> > generalize all the way back to <topic>. Thus, if someone were to
> > specialize <design> from <explanatory> and someone wanted
> to use that
> > specialized content in an unspecialized environment, they
> would have
> > to generalize to <topic>. If in some future release of DITA
> <concept>
> > is also specialized from <explanatory> then they could
> generalize back
> > to <explanatory> and get a closer fit for processing in the
> > unspecialized environment.
> >
> > Thinking of records, how about archival?
> >
> > How about moving the semantics of 'event' up to the abstract layer,
> > and let the busdocs type be 'record'? I haven't thought of any
> > adjectives around 'event' but it does open up the search
> field a bit.
> > We've been asking what words cluster around 'record', and
> we can also
> > ask what words cluster around 'event'.
> >
> > /Bruce
> >
> > > -----Original Message-----
> > > From: rockley@rockley.com [mailto:rockley@rockley.com]
> > > Sent: Monday, April 12, 2010 12:22 PM
> > > To: Bruce Nevin (bnevin)
> > > Cc: manning@rockley.com; rob.hanna@wolterskluwer.com;
> > > tgrantham@timgrantham.com; zrendon@ptc.com; rockley@rockley.com
> > > Subject: Adjectives vs nouns
> > >
> > > At the end of today's meeting we agreed to send a list of
> > the possible
> > > options for temporal to the list and to point out that we need an
> > > adjective form of the word. However, we may wish to modify our
> > > position on the use of an adjective for the following reason.
> > >
> > > Our abstract layer currently consists of:
> > >
> > > -Procedural
> > > -Explanatory
> > > -Descriptive
> > > -Advisory
> > > -Criterial
> > > -'Temporal'
> > >
> > > However, we are going to continue with concept, task and
> reference;
> > > not procedural, explanatory and descriptive.
> > >
> > > Therefore, should we drop the requirement for an adjective
> > form of the
> > > term?
> > >
> > > I wanted to check on our feelings on this criteria before I
> > send the
> > > list of options to the subcommittee.
> > >
> > > Please let me know by EOB today what your thoughts are on
> this so I
> > > can post the list.
> > >
> > > Thanks.
> > >
> > > Ann
> > >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]