dita — archive

[Eliot Kimber <ekimber@contrext.com>]

Discussion on today's TC call, not on the list. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 1/13/15, 11:50 AM, "Eliot Kimber" <ekimber@contrext.com> wrote: >To follow up: based on the discussion on the list, I think we arrived at >the following understanding and intent: > >1. The language of the 1.2 spec is indeed ambiguous as regards the number >of element types allowed in a single constraint module. > >2. The 1.2 spec allows multiple constraint modules per vocabulary module. >Which means that it is practically possible to have multiple constraints >with one element type per constraint module for a single vocabulary module >if you want. (Bob Thomas helped me understand that I had misinterpreted >the requirement for one vocabulary module per constraint as implying the >inverse, namely one constraint per module, but that is not what the 1.2 >spec says and other language clearly implies that you can have multiple >constraint modules per vocabulary module. There is another clause that >says you can only have one constraint module that restricts the set of >domain elements to be included from a given domain, but that's a very >specific case and does not apply more generally.) > >3. The 1.3 spec should allow a single structural constraint module to >constrain multiple element types within the structural type (topic or map >type). This is a relaxation of the strict reading of the 1.2 spec but >cannot break any existing constraint implementations and makes existing >constraint modules that do have multiple element types explicitly >conforming. > >4. The current module naming rules will need to be clarified or relaxed to >allow more flexibility in naming files so that multi-element-type >structural constraint modules are clearly allowed and provided for. My >suggestion would be to use the name of the structural type as the "element >type name", e.g. "topic", "concept", "bookmap" when the constraint >constrains multiple element types within the structural type. The intent >of the naming convention is to make the relationship between the >constraint module and the corresponding vocabulary module clear. > >Cheers, > >E. >————— >Eliot Kimber, Owner >Contrext, LLC > http://contrext.com > > > > >On 1/13/15, 10:30 AM, "Eliot Kimber" <ekimber@contrext.com> wrote: > >>The language specific in the discussion of structural constraints is >>clear >>that a single constraint module can constrain multiple elements and that >>is definitely the intent of the spec. There is no other interpretation >>that makes practical sense as the spec also says that there can be at >>most >>one constraint module for a given vocabulary module. >> >>I think the confusion might come from the language for the names of >>structural constraint modules, which talk about the tagname the >>constraint >>relates to. For a constraint module that constrains multiple element >>types >>within the structural module, the filename should refer to the structural >>type (e.g, topic, concept, task). The naming rules are a little bit weak, >>as we've discussed. The intent of the naming rules is that the name of >>the >>constraint module makes it clear what module the constraint applies to >>and >>the general nature or purpose of the constraint. >> >>Cheers, >> >>E. >>————— >>Eliot Kimber, Owner >>Contrext, LLC >> http://contrext.com >> >> >> >> >>On 1/13/15, 9:26 AM, "Kristen James Eberlein" >><kris@eberleinconsulting.com> wrote: >> >>> >>> >>> >>> >>> >>> >>> A fairly significant question has cropped up as result of the >>> constraints review. I polled four TC members yesterday and posed the >>> following question: >>> >>> "Off the top of your head, for a non-domain constraint module, which >>> of the following is true? >>> >>> >>>* A constraint module can restrict only a single element. >>> >>>* A constraint module can restrict only a group of elements that >>> are defined in the same . mod file. >>> >>> >>> The TC members were equally split on what is the correct answer >>> to the question. >>> >>> I went to the original proposal from Erik Hennum, and confirmed >>> that this was indeed ambiguous in both the DITA 1.2 proposal and >>> the DITA 1.2 spec. >>> >>> We do need to settle this ... >>> >>> -- >>> Best, >>> Kris >>> >>> Kristen James Eberlein >>> Chair, OASIS DITA Technical Committee >>> Principal consultant, Eberlein Consulting >>> www.eberleinconsulting.com < http://www.eberleinconsulting.com > >>> +1 919 682-2290; kriseberlein (skype) >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>>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 >> >> > > > > --------------------------------------------------------------------- >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 > >