Re: [dita] FW: DocBook Customization

[Eliot Kimber <ekimber@reallysi.com>]

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" <mpriestl@ca.ibm.com> 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
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25
> 
> 
> 
> Dana Spradley <dana.spradley@oracle.com>
> 07/14/2009 12:54 PM
> 
> To
> dita@lists.oasis-open.org
> 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:jogden@ptc.com]
> Sent: Wednesday, July 08, 2009 2:42 PM
> To: dita
> Subject: [dita] FW: DocBook Customization
> 
> 
> 
> 
>> -----Original Message-----
>> From: Dick Hamilton [mailto:rlhamilton@frii.com]
>> 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
>> rlhamilton@frii.com
>> ===============================================================
>> 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:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
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>