OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Constraint Mechanism [was 1.2 Requirements Ranking]


Erik Hennum wrote:
> Hi, Eliot:
> 
> Maybe a particularly good discussion to have, given the issue Paul 
> raised today about the long term roadmap for DITA...

Something that Erik's comments bring up that we should consider as well 
is the potential for the process of trying to define a constraint 
mechanism to force us to revisit the entire specialization mechanism and 
its details.

I don't think we, as a TC or as a community could afford to that 
now--it's too new and people are just now starting to get their heads 
around what specialization means and becoming comfortable with the idea 
that specialization might be appropriate for them, much less applying it 
in sophisticated ways that would benefit from more sophisticated 
constraint mechanisms.

Therefore, I would like to avoid for now any discussions that would have 
the effect of requiring me, for example, to say things like "aspect X of 
the current specialization architecture is {broken|misguided|not quite 
right|essential for the safety of the universe} for this reason...".

I fear that as soon as you start discussing things like the implications 
of generalization on constrained DTDs you get to that point very quickly.

I think that *eventually* we need to have that discussion, but I think 
it needs to be in the context of a larger 2.0 discussion, when we have 
more freedom to rethink the core DITA architecture and syntax.

It's clear to me that, at the moment, the specialization mechanism as 
currently defined works at least well enough to realize the intended 
benefits, in particular, the ability to apply generic processing to 
specialized instances. Constraint specification beyond what one can 
already potentially do with DTDs or XSD or RelaxNG or Schematron seems 
like pre-mature optimization in the face of more pressing and 
easy-to-implement requirements.

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]