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
http://dita.xml.org/blog/25
"Eliot Kimber"
<>
10/25/2007 04:03 PM
To
Michael Priestley/Toronto/IBM@IBMCA
cc
"dita" <>
Subject
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"
<> 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
processing.
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
standpoint.
[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.
Cheers,
E.
--
W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com
Sent using the Microsoft Entourage 2004 for Mac Test Drive.
