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?
- From: Deborah_Pickett@moldflow.com
- To: "Ogden, Jeff" <jogden@ptc.com>
- Date: Wed, 17 Oct 2007 14:56:00 +1100
"Ogden, Jeff" <jogden@ptc.com> wrote
on 16/10/2007 07:39:06 AM:
> 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?
I prefer for the standard to make no promises, and
let specializers take as much rope as they need.
> 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),
Interesting that you bring up URIs. Inevitably
some specialization is going to come along that wants to link to somewhere
in a way that isn't covered by existing hrefs. We don't have a standard
way of making new href-like attributes, and to cater to those specializations
we need to. Or do we: is this what data/@href is for?
And because that made me think of xlink, it reminds
me that something we have also not discussed for an awfully long time is
namespaces. Are DITA specializers allowed to add namespaced attributes?
> 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.
This is a little tangential, but depending on how
we approach a solution, it might not be.
I suppose that a common scenario is that I have a
document that contains a specialization, but for $transform I don't have
any processing to handle that specialization, so I get fallback behaviour.
Sometimes fallback behaviour is fine. The UI
domain, for instance, is hardly groundbreaking, and falling back to <ph>
is not going to hurt.
Sometimes fallback behaviour is ugly. The Utilities
domain's <imagemap> element doesn't really work if rendered as a
plain <fig>: you end up seeing the coordinates as plain text. (I
suppose the real culprit here is the <shape> element rather than
its ancestor imagemap, and that if it were omitted you'd get something
at least presentable.)
How can the processor know when fallback behaviour
is acceptable? Is there some way for a <shape> to say to the
processing for its base topic/keyword, "skip me" (or "die")?
(Obviously the answer today is "no, there isn't", so really
my question is "is this something we want?".)
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]