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?



"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]