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:ekimber@reallysi.com]
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"