Fwd: [dita] Cascading of <source> and <othermeta> in maps

I meant to sent this to the list instead of to just Don. Sorry for the redundant message Don.

---------- Forwarded message ----------
From: Bob Thomas <bob.thomas@tagsmiths.com>
Date: Fri, Apr 24, 2015 at 10:38 AM
Subject: Re: [dita] Cascading of <source> and <othermeta> in maps
To: "Don R. Day" <donday@donrday.com>

Like Don, I have no desire to change the “cascade” terminology in the 1.3 specification at this point. But, his observations are thought provoking and make for interesting discussion.

I agree that the term “cascade” is processing oriented. What’s really needed is a term for the opposite direction of “inheritance”. The closest term I can think of is “extent”.

I consider inheritance to be an intrinsic characteristic of elements that have been derived from other elements. Similarly, I consider extent to be an intrinsic characteristic of those elements that have been flagged as “yes” in the “Does it cascade” column. The value associated with such an element is immutably bound to that element, even though the property that it establishes within the information set is mutable through override by a like-named element further down the map tree.

Best Regards,

Bob

On Thu, Apr 23, 2015 at 6:21 PM, Don R. Day <donday@donrday.com> wrote:

I had an insight while reading this discussion. The term "cascade" is processing oriented; there is no cascade without a specific implementation behavior somewhere. So when I looked at the table of elements under the "Does it cascade" column, I suddenly realized that the Yes/No values are defining processing flags, not intrinsic properties of the elements (what the Spec ought to be defining). And the properties I see behind the Yes/No values are Mutable (meaning programmatic processing can influence the effective value of the element) and Immutable (meaning the element represents a persistent value that should change only by editorial rather than by programmatic process).

As a result, I see more clearly why <source> and other metadata elements are immutable--their values are warranted to persist, and are auditable in the sense that they represent facts rather than states (facts don't change; states do). This fits in with seeing DITA as a data model rather than in terms of processing. I don't suggest changing any wording for now, only that this viewpoint might help in coming up with responses to future questions about the cascade.

Don R. Day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot

On 4/23/2015 3:43 PM, Eliot Kimber wrote:

Ah, I clearly haven't paid enough attention to the @cascade feature. So
forget that comment.

Cheers,

E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 4/23/15, 3:16 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:

Hi Eliot,

I hesitate to respond to agreement, but I just want to clarify:

With the new @cascade element a map author could turn on cascading of
either element if they wanted it.

The @cascade attribute is defined as only dealing with attributes. It's
specifically intended to handle the merging or not merging of attribute
values; it does turn cascading itself off even for attributes.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

<dita@lists.oasis-open.org> wrote on 04/23/2015 14:50:00:

From: Eliot Kimber <ekimber@contrext.com>
To: Robert D Anderson/Rochester/IBM@IBMUS, DITA TC
<dita@lists.oasis-open.org>
Date: 04/23/2015 14:50
Subject: Re: [dita] Cascading of <source> and <othermeta> in maps
Sent by: <dita@lists.oasis-open.org>

It makes sense to me that <source> would *not* cascade as its purpose is
to indicate the source of the resource referenced by the topicref and
doesn't inherently imply the source of any descendant topicrefs.

Likewise, I've always equated <othermeta> to <data> and agree that they
should have the same cascading behavior.

With the new @cascade element a map author could turn on cascading of
either element if they wanted it.

Cheers,

Eliot
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com

On 4/23/15, 1:50 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:

Jarno Elovirta pointed out to me today (based on an issue from a

DITA-OT

user) that we have conflicting information in the spec about cascading
metadata - specifically the two elements <source> and <othermeta>. This
language is in DITA 1.2 and remains in the latest DITA 1.3 draft.

The following topic lists <source> and <othermeta> as metadata elements
that cascade within a map:

http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/cascading-in-a-dit
am
ap.html

The following topic is more comprehensive and covers every metadata
element in the map, listing whether it cascades within a map or from

map

to topic. It says that <source> and <othermeta> cascade from <topicref>
to a referenced topic, but that they do not cascade within a map:

http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/reconciling-topic-
an
d-map-metadata.html

I worked quite a bit on that second topic in DITA 1.2 so that's what I
was most familiar with - I thought that these two elements did not
cascade within a map. I vaguely remember that <othermeta> was discussed
during the 1.2 process, and was grouped with <data> as a generic

metadata

element that cannot be assumed to cascade. I don't remember any

specific

discussion of <source>.

Given that the two topics directly contradict each other, we need the

TC

to weigh in on which is correct. Ideally we can also get rid of this
duplicate info in the spec. Until now it has been in the back of my

mind

as one of those things I'd like to fix but may leave alone, given our
time constraints and given that the two topics existed in 1.2.

Thanks,

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

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

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

This email has been checked for viruses by Avast antivirus software.
www.avast.com

Bob Thomas

+1 720 201 8260

Skype: bob.thomas.colorado

Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype

Time zone: Mountain (GMT-7)

Bob Thomas

+1 720 201 8260

Skype: bob.thomas.colorado

Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype

Time zone: Mountain (GMT-7)

dita message