[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Question cropping up as a result of constraints review
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]