Next in thread →
Next in month →
RE: [dita] FW: DocBook Customization
I think that's SHOULD versus MUST. Michael Priestley, Senior Technical Staff Member (STSM) Lead IBM DITA Architect http://dita.xml.org/blog/25 Dana Spradley <> 07/15/2009 02:57 PM To Eliot Kimber <>, Michael Priestley/Toronto/IBM@IBMCA cc Subject RE: [dita] FW: DocBook Customization Agreed - so long as when Michael says "should be something you try only where valid extension mechanisms aren't enough", he doesn't mean "SHOULD be something you only try..." That is - we're giving advice here, or encouraging people to use the valid mechanisms - but not mandating it. Since we can hardly mandate anything to someone determined to break the spec. --Dana -----Original Message----- From: Eliot Kimber [mailto:] Sent: Tuesday, July 14, 2009 10:18 AM To: Michael Priestley; Dana Spradley Cc: dita Subject: Re: [dita] FW: DocBook Customization It's probably also useful, as the 1.1 language did, to make a clear distinction between non-conforming things done purely to support authoring, and non-conforming things done that persist in data. That is, modifying a schema in a way that the *schema* doesn't conform to the rules for vocabulary modules but the documents that conform to it *do* conform to the DITA spec is materially different from modifying a schema such that the documents themselves do not conform. For example, hacking a schema to enable dynamic generation of enumerated attribute declarations, as described on today's call, doesn't affect the conformance of the documents, even though the schema itself can't conform as implemented (because it's doing something not allowed for in the implementation rules). But adding arbitrary attributes to individual element types results in *documents* that cannot conform to the DITA spec. This is sometimes required, for example to support CMS systems that impose their own attributes, but both the systems that do that and the users of those systems need to clearly understand that the resulting documents do not, in that form, conform to DITA, and must therefore be modified before being interchanged. Note that in this case you can use a conforming constraint module to add the attributes to an otherwise-conforming vocabulary module, so the vocabulary modules themselves in this case conform to the rules for modules (other than adding arbitrary attributes). In general, I think we are or should be more concerned about changes that make documents non-conforming and that bias should probably be reflected in the spec if it isn't already. Cheers, E. On 7/14/09 12:02 PM, "Michael Priestley" <> wrote: > As long as we have wording that makes it explicit that the customization - > ie breaking the spec - should be something you try only where valid > extension mechanisms aren't enough. > > This is particularly true now that we have the constraints mechanism in > 1.2. There are a whole set of requirements that led people to customize > with 1.1 or 1.2 where now there is a DITA-valid way to do so. > > Michael Priestley, Senior Technical Staff Member (STSM) > Lead IBM DITA Architect > > http://dita.xml.org/blog/25 > > > > Dana Spradley <> > 07/14/2009 12:54 PM > > To > > cc > > Subject > RE: [dita] FW: DocBook Customization > > > > > > > Thanks for forwarding this Jeff. > > So it seems we should call the kind of customization we're including in > the specification "extension" or similar - not "customization." > > Then as Dick says, we should include a section on "Customization" per se > at the end that recognizes that "there is no question that people need and > want to customize" DITA in its proper sense, using generic XML or other > techniques beyond those we specify, but "if you must, you're on your own > and not conformant." > > --Dana > > -----Original Message----- > From: Ogden, Jeff [mailto:] > Sent: Wednesday, July 08, 2009 2:42 PM > To: dita > Subject: [dita] FW: DocBook Customization > > > > >> -----Original Message----- >> From: Dick Hamilton [mailto:] >> Sent: Wednesday, July 08, 2009 4:30 PM >> To: Ogden, Jeff >> Subject: DocBook Customization >> >> Jeff, >> >> I'm an observer on the DITA TC, but not a member, so my >> attempt to send the attached response concerning the thread >> on DocBook Customization got bounced. >> >> Since you were an active participant, I hope you don't mind >> if I send the response to you, instead. If you find it useful, >> feel free to post it on the list. If not, the bit-bucket is >> ok, too:). >> >> Thanks, >> Dick Hamilton >> >> =============================================================== >> I've been following this thread with some interest and have >> to chime in about "DocBook Customization" from the perspective >> of a longtime DocBook user. >> >> There seems to be an implication in some messages that >> customization is part of the DocBook standard. That is not >> the case. If you change DocBook, the result is no longer >> DocBook. >> >> That said, there is no question that people need and want >> to customize DocBook, and the DocBook TC has always realized >> this. That's why the design was done with customization in >> mind and why the spec and Definitive Guide both discuss >> customization. But, both clearly state that if you customize, >> you are not conformant. >> >> So, I agree with Eliot and Jeff that you should dictate against >> what this thread calls "DocBook Customization," in the same way >> that DocBook dictates against "DocBook Customization." I.e., if >> you must, you're on your own and not conformant. >> >> Dick Hamilton >> --------------------------------- >> XML Press >> XML for Technical Communicators >> http://xmlpress.net/managingwriters.html >> (970) 231-3624 >> >> >> >> > > > --------------------------------------------------------------------- > 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 > > > --------------------------------------------------------------------- > 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 > > ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: <mailto:> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://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
Next in thread →
Next in month →