[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Vertical Industry Vocabulary in DITA 1.3
Eliot, Thank you for expressing this opinion, which exactly matches mine: ". . . vertical requirements should start to be satisfied through separate specifications and not baked into the core DITA vocabulary" Bravo! - Bryan Schnabel -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Wednesday, February 23, 2011 4:34 AM To: dita Subject: [dita] Vertical Industry Vocabulary in DITA 1.3 [This is a reaction to Jontan Lundin's responsse to the Refinements to DITAVAL for Flagging: not to the substance of his post but to the implications of the questions and requests that he's making. I'm starting a new thread because this is a meta-comment, not a direct response to Jontan.] I can see value in having one or more machine-industry-specific @props specialization modules and declaring them is almost trivially easy. That could be done unilaterally at any time without a need to add them to the base DITA spec. That is, the Machine Industry SC, or any other community-specific SC or anyone else, can declare and provide such modules *at any time* without the need for the TC to do anything more than approve the work product as required by OASIS rules. I have been hopeful that the DITA for Publishers project would serve as an example of an industry meeting its own requirements through development of its own specializations separate from the TC, but I don't think its reached a level of maturity sufficient to generate enough visibility to make that point. But nevertheless, I think DITA for Publishers is a good example of just that: an industry-specific group defining its own vocabulary without the need to work through the TC or even through OASIS. Once D4P is more than just me I will look for the appropriate standards venue to take it over, and that might be OASIS or it might be IDEAlliance or it might be SPECTRE, I don't know yet. The point is that it doesn't have to be OASIS. But the larger issue is: I think this is an example of an area where vertical requirements should start to be satisfied through separate specifications and not baked into the core DITA vocabulary. Machine Industry is just one example. Publishing is another, Learning and Training yet another. The original selection attributes are really legacy that, if @props had been in DITA 1.0, would (A) have been specializations of @props (and could be today if we cared) (B) could have been in a tech-doc-specific module, rather than being mandatory. We could back-define those attributes as @props specializations in DITA 1.3 if we wanted to since that would change any functional aspects of those attributes or processors that recognize them today based merely on their names. That would make the DITA vocabulary cleaner and more consistent, leaving only @rev as a special case because of its "flagging only" semantic (and maybe we need a base attribute from which @rev could be specialized--hmmm). One of the reasons that I harp on the need for all production users of DITA to create local shell document types is that I know they will need to specialize from @props sooner rather than later, because the base set of selection attributes is clearly not sufficient for most users of DITA. The TC and the Adoption TC need to make that point more clearly. For DITA 1.3, rather than continuing to add more and more stuff to the base vocabulary, I would like us to start moving vertical vocabulary into separate specifications, reserving the base vocabulary for things that are either of universal utility or essential to the architecture as a whole. We should not be adding any new attributes or elements that are specific to any particular industry or use domain. This goes also to the "DITA is too complex" issue: we have to start making a much clearer distinction between "DITA" as a core architecture and base vocabulary, and "applications of DITA" that satisfy specific requirements of specific communities. We need to do two things in this regard: 1. Produce separate specifications out of the TC for industry-specific vocabulary we've already agreed to do (Machine Industry, Learning and Training, BusDocs, etc.) 2. Help the community at large understand that they don't require the TC to create their own community-specific standard DITA applications. Essentially, we need to wean the community off their dependence on us for satisfying their local requirements (where by "local" I include large communities like "Publishers" or "Pharma"). The way we've been doing things is unsustainable and we have to stop. That is, we need to start using DITA's specialization facility for what it enables: letting communities of interest unilaterally satisfy their own markup requirements. Our focus should be entirely on architectural aspects that enable satisfaction of requirements that cannot be met through specialization, that is things that require new generic facilities or extension of base types in some way. Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]