[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] How much flexibility do specializers have to makeexceptions to behaviors that are outlined in the DITA standard?
On 10/15/07 4:39 PM, "Ogden, Jeff" <jogden@ptc.com> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]