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.
I realized in my wording below I used
the word syntax twice to mean two different things :-)
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 standard; the expected
behavior should be default.
Michael Priestley
Lead IBM DITA Architect
http://dita.xml.org/blog/25
Michael Priestley/Toronto/IBM@IBMCA
10/25/2007 03:21 PM
To
"Eliot Kimber" <>
cc
"dita" <>
Subject
Re: [dita] How much flexibility do specializers
have to make exceptions to behaviors that are outlined in the DITA standard?
Hi Eliot,
Re:
>- All addressing of DITA-governed content by DITA-governed content.
That is,
>you cannot, within a specialization, change the rules for resolving
hrefs
>(or any other DITA-defined addressing mechanism)) to DITA-based content.
Couldn't the implementer choose to create hoverhelp for a link to APItopics
by summarizing the syntax, rather than always pulling the shortdesc? Agreed
the syntax should be consistent, but why limit what we do with that syntax?
>- Conref. You cannot change the constraints or effective result that
conref
>produces.
Couldn't an implementer decide that they want to limit reuse in their organization
to content coming from specific directories? For example, check the conref
path to ensure that it starts with "/reuse/"?
It seems to me that one of the advantages of having conref as an explicit
process rather than something that happens as part of parsing (as with
entities or XIncludes) is that you can, as an implementer, choose to enhance
or restrict the processing according to your local requirements.
Michael Priestley
Lead IBM DITA Architect
http://dita.xml.org/blog/25
"Eliot Kimber"
<>
10/25/2007 03:10 PM
To
"dita" <>
cc
Subject
Re: [dita] How much flexibility do specializers
have to make exceptions to behaviors that are outlined in the DITA standard?
On 10/15/07 4:39 PM, "Ogden, Jeff" <> wrote:
> The question that is up for discussion is, are specializers free to
do
> anything they want or are there some things that the DITA Standard
makes
> out of bounds even for user defined specializations that aren't part
of
> the official DITA standard?
> From my point of view, I'd like to see some limits on what specializers
> can do in terms of referencing behaviors (what legal DITA URI's can
look
> like and what they mean), and when there are interactions such as
> property cascading behavior between one document and another (from
a map
> to a topic or from a map to a map to a topic). I want to increase
the
> likelihood that DITA users can share their documents, including
> specialized documents, with others or move the documents into new
> processing environments and still get good results. I want to
reduce
> the amount of reimplementation users have to do when they share their
> documents or move into new processing environments.
The DITA specification defines a number of core processing semantics that
constitute the core processing infrastructure that makes DITA both work
functionally (that is, when implemented, those features produce the result
that you presumably want because you're using DITA) and allows documents
and
document processing to be reasonably interchangeable.
I think that this infrastructure includes the following:
- All addressing of DITA-governed content by DITA-governed content. That
is,
you cannot, within a specialization, change the rules for resolving hrefs
(or any other DITA-defined addressing mechanism)) to DITA-based content.
- Conref. You cannot change the constraints or effective result that conref
produces.
Where things start to get a little cloudier, and where I think this
discussion started, is in the area of the implications for topic references
and in particular how do topic references affect the effective properties
of
the topics they reference?
The issue here is that while this area can be viewed as concrete in the
way
that addressing and conref are, it can also be seen as a matter of
presentation style. For example, for some specializations of metadata used
within topicref I want their values to propagate and replace values on
referenced topics and for other values I do not. A blanket DITA-defined
rule
of "metadata always propagates" or "metadata never propagates"
would be
wrong some of the time so we can't define it. That leads to Paul's original
question of how can specializations express their intent in a case like
this
that allows a tool like Arbortext Editor to do the expected thing
automatically? Clearly in this specific case there's a need for some sort
of
schema-level way to indicate the processing intent.
Simple enough to design for this case, but how many cases are there?
Probably lots. That suggests you need a more general mechanism for this
sort
of thing. That will be, necessarily, complex. Easier to just punt and say
"DITA has no opinion". But that doesn't help Paul. Seems like,
for the
moment, there's no easy answer to this question.
At a minimum DITA has to define clear default behaviors for those areas
where processors can legitimately do different things.
I guess I would need to see some specific cases where a specialization
wants
to deviate from either the defined or suggested behavior to evaluate whether
or not the deviation is processing or style, there's a way to usefully
parameterize the behavior choices or whether the requirement can be
satisfied in a different way. Or where, as above, DITA either says nothing
or isn't clear and there are multiple useful ways that a processor could
behave.
It's also worth saying that while DITA should "just work" that's
always in
terms of the default behavior, whatever it is, as defined by the DITA spec.
Specializations that want something other than the default are on their
own
and there should be no expectation on anyone's part that
specialization-specific stuff will magically happen without some
implementation effort.
In that respect, DITA-based applications are no different from any other
purpose-built XML application in that you may have to do a bit of local
customization of your generic tools to get what you want. However, with
DITA
it should always be less (or no greater than) it would have otherwise been
because DITA gives you so much out of the box.
For example, for demonstration purposes I've defined a specialization of
reference for capturing animal field guide entries, including
specializations of <data> for capturing the Linnaean classification
of the
animals described. No DITA-aware processor is going to give me any special
support for authoring these classifications but I'd probably want to build
a
little classification editor for these values since they need to be
validated and could be gathered from external data sources and whatnot.
I
would not fault any DITA-supporting editor for not providing that but I
would expect a way to add it without too much difficulty.
Cheers,
Eliot
--
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.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
