Eliot, thanks for your comments and for
getting this conversation started again.
In response to Michael’s
comment/question:
> 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/"?
I don’t see a problem with this as
long as the implementer is being more restrictive than what is required by the
standard. The standard says that conref values are URIs that reference
DITA content with a number of checks to make sure they content being referenced
is legal or is likely to be legal in the new context. Limiting the
references to a particular path isn’t violating that. The conref values
that start with /reuse/ will always be valid URI and with a bit of luck the
thing being referenced will be DITA content that is legal in the current
content. An implementation will not have to do anything special to make the
required checks. You can’t expect other implementations to impose the
same limitations automatically, but that is OK.
-Jeff
From: Michael
Priestley [mailto:]
Sent: Thursday, October 25, 2007
3: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
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
