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] How much flexibility do specializers have to make exceptions tobehaviors that are outlined in the DITA standard?

I guess I was having trouble separating out "addressing" as a behavior from the various actual processes that use addressing. I see your point.

I was thinking of addressing as "what the syntax means" - for example topicid/elementid - we wouldn't want that to be overridden by processing, it's not even clear to me what overriding that would mean. But I buy that processing for addresses should not ignore or misinterpret the actual information in the address. That said, all the processes that do something with the info at that address should be overrideable - like shortdesc pulling, link creation, etc. etc.

For conref, which goes beyond the address, where do we draw the line? Is there a problem with my example? Or is it another case where the syntax's meaning is preserved, so even if the exact behavior as described in the spec doesn't apply it still is preserving the important part of the process, ie the meaning of the address?

As another conref example: we say you can generalize on the fly where necessary/appropriate - I can imagine someone overriding the generalization to, for example, generate titles for specialized sections that are being generalized during conref. Is that ok? Are there other conref overrides that wouldn't be ok, for example overriding the process to allow conref across specializations without generalization at all?

Michael Priestley
Lead IBM DITA Architect

"Eliot Kimber" <ekimber@reallysi.com>

10/25/2007 04:03 PM

Michael Priestley/Toronto/IBM@IBMCA
"dita" <dita@lists.oasis-open.org>
Re: [dita] How much flexibility do specializers have to make exceptions to behaviors that are outlined in the DITA standard?

On 10/25/07 2:41 PM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> Clarification:
> in the href overriding example, a processor might choose to create a
> preview by summarizing specialized elements in a target's <refsyn> or
> equivalent, rather than using the <shortdesc>. This wouldn't affect the
> syntax of the href, but does change the expected processing from the
> default.

What you've described is rendition, not address resolution.

That is, when I say "addressing" I mean "the object that is addressed by the
href value" which is different with what you do with that thing once you
have it.

That is, how or if you produce tooltips in some rendition is entirely a
matter of style. What those tooltips apply to (or at least what the initial
source of their ultimate value is) is a function of invariant address

That is, you can choose to produce or not produce tooltips, you can't change
what "mytopic.dita#topicid/elementid" means from an address resolution

[Note that this is one problem with DITA not using standard addressing
mechanisms: it provides no built in mechanism for choice in how you do
addressing at the fragment identifier level, which means you either have
non-DITA stuff or you use URIs that have to be interpreted by a specific URI
resolver. This is a fundamental problem with DITA 1.x that must be corrected
in DITA 2.]

> Main point remains the same: I think everything in "expected behavior" is
> expected default behavior; everything in "expected markup/syntax" is
> required unless otherwise stated. The syntax for href and conref should be

But the point is that that there are some things in DITA that are not
"expected behavior" but "required behavior", which includes, I assert, all
addressing and conref.



W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770

Sent using the Microsoft Entourage 2004 for Mac Test Drive.

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