OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  subjectScheme and normative language

    Posted 04-15-2014 11:32
    The spec does not use any normative language concerning our expectations regarding processors and subject scheme maps. I think we need to consider changing this, especially as DITA 1.3 will introduce @deliveryTarget and deprecate @print. Here are some changes for us to consider: DITA 1.2 language DITA 1.3 language (suggested) Tools may validate controlled values for attributes by reference to the subject scheme map. Tools SHOULD validate controlled values for attributes by reference to the subject scheme map. If controlled values for a metadata attribute are defined using the subject scheme map, tools may give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value. If controlled values for a metadata attribute are defined using the subject scheme map, tools MAY give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value. The list of defined values are not validated by basic XML parsers. Instead, the defined values should be validated by DITA processors. The list of defined values are not validated by basic XML parsers. Instead, the defined values SHOULD be validated by DITA processors. Processors should be aware of hierarchies of attributes defined in subject scheme maps, and process them differently than they might if the attributes were not defined in a hierarchy. Processors SHOULD be aware of hierarchies of attributes defined in subject scheme maps, and process them differently than they might if the attributes were not defined in a hierarchy. If any other values are encountered [other than those defined in the subject scheme as valid for the attribute], processors validating against the scheme should give a warning If any other values are encountered [other than those defined in the subject scheme as valid for the attribute], processors validating against the scheme SHOULD give a warning An enumeration may be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes therapist and does not explicity identify novice , processing should apply filtering to all subsets of therapist. If filtering includes novice but does not explicity exclude therapist , processing should include the general therapist content because it applies to novice . If flagging explicity includes therapist but is not set explicity for novice , processing should apply the therapist flag to the novice content as a special type of therapist. An enumeration can be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes therapist and does not explicity identify novice , processing SHOULD apply filtering to all subsets of therapist. If filtering includes novice but does not explicity exclude therapist , processing SHOULD include the general therapist content because it applies to novice . If flagging explicity includes therapist but is not set explicity for novice , processing SHOULD apply the therapist flag to the novice content as a special type of therapist. Important caveat: This needs to be rewritten so that the normative language is separated from the example. And we should fix the typo also :) Thoughts? -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype)


  • 2.  Re: [dita] subjectScheme and normative language

    Posted 04-15-2014 11:56
    I think this is an important change. Might help tools get it right.  In the third item should read "the list of defined values is" no "are".  JoAnn Sent from my iPhone JoAnn Hackos Comtech On Apr 15, 2014, at 6:31 AM, "Kristen James Eberlein" < kris@eberleinconsulting.com > wrote: The spec does not use any normative language concerning our expectations regarding processors and subject scheme maps. I think we need to consider changing this, especially as DITA 1.3 will introduce @deliveryTarget and deprecate @print. Here are some changes for us to consider: DITA 1.2 language DITA 1.3 language (suggested) Tools may validate controlled values for attributes by reference to the subject scheme map. Tools SHOULD validate controlled values for attributes by reference to the subject scheme map. If controlled values for a metadata attribute are defined using the subject scheme map, tools may give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value. If controlled values for a metadata attribute are defined using the subject scheme map, tools MAY give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value. The list of defined values are not validated by basic XML parsers. Instead, the defined values should be validated by DITA processors. The list of defined values are not validated by basic XML parsers. Instead, the defined values SHOULD be validated by DITA processors. Processors should be aware of hierarchies of attributes defined in subject scheme maps, and process them differently than they might if the attributes were not defined in a hierarchy. Processors SHOULD be aware of hierarchies of attributes defined in subject scheme maps, and process them differently than they might if the attributes were not defined in a hierarchy. If any other values are encountered [other than those defined in the subject scheme as valid for the attribute], processors validating against the scheme should give a warning If any other values are encountered [other than those defined in the subject scheme as valid for the attribute], processors validating against the scheme SHOULD give a warning An enumeration may be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes "therapist" and does not explicity identify "novice", processing should apply filtering to all subsets of therapist. If filtering includes "novice" but does not explicity exclude "therapist", processing should include the general therapist content because it applies to "novice". If flagging explicity includes "therapist" but is not set explicity for "novice", processing should apply the "therapist" flag to the "novice" content as a special type of therapist. An enumeration can be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes "therapist" and does not explicity identify "novice", processing SHOULD apply filtering to all subsets of therapist. If filtering includes "novice" but does not explicity exclude "therapist", processing SHOULD include the general therapist content because it applies to "novice". If flagging explicity includes "therapist" but is not set explicity for "novice", processing SHOULD apply the "therapist" flag to the "novice" content as a special type of therapist. Important caveat: This needs to be rewritten so that the normative language is separated from the example. And we should fix the typo also :) Thoughts? -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting 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


  • 3.  RE: [dita] subjectScheme and normative language

    Posted 04-15-2014 19:03
    I agree with these suggestions.   - Deb   From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Kristen James Eberlein Sent: Tuesday, April 15, 2014 5:31 AM To: DITA TC Subject: [dita] subjectScheme and normative language   The spec does not use any normative language concerning our expectations regarding processors and subject scheme maps. I think we need to consider changing this, especially as DITA 1.3 will introduce @deliveryTarget and deprecate @print. Here are some changes for us to consider: DITA 1.2 language DITA 1.3 language (suggested) Tools may validate controlled values for attributes by reference to the subject scheme map. Tools SHOULD validate controlled values for attributes by reference to the subject scheme map. If controlled values for a metadata attribute are defined using the subject scheme map, tools may give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value. If controlled values for a metadata attribute are defined using the subject scheme map, tools MAY give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value. The list of defined values are not validated by basic XML parsers. Instead, the defined values should be validated by DITA processors. The list of defined values are not validated by basic XML parsers. Instead, the defined values SHOULD be validated by DITA processors. Processors should be aware of hierarchies of attributes defined in subject scheme maps, and process them differently than they might if the attributes were not defined in a hierarchy. Processors SHOULD be aware of hierarchies of attributes defined in subject scheme maps, and process them differently than they might if the attributes were not defined in a hierarchy. If any other values are encountered [other than those defined in the subject scheme as valid for the attribute], processors validating against the scheme should give a warning If any other values are encountered [other than those defined in the subject scheme as valid for the attribute], processors validating against the scheme SHOULD give a warning An enumeration may be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes "therapist" and does not explicity identify "novice", processing should apply filtering to all subsets of therapist. If filtering includes "novice" but does not explicity exclude "therapist", processing should include the general therapist content because it applies to "novice". If flagging explicity includes "therapist" but is not set explicity for "novice", processing should apply the "therapist" flag to the "novice" content as a special type of therapist. An enumeration can be defined with hierarchical levels by nesting subject definitions. If filtering or flagging excludes "therapist" and does not explicity identify "novice", processing SHOULD apply filtering to all subsets of therapist. If filtering includes "novice" but does not explicity exclude "therapist", processing SHOULD include the general therapist content because it applies to "novice". If flagging explicity includes "therapist" but is not set explicity for "novice", processing SHOULD apply the "therapist" flag to the "novice" content as a special type of therapist. Important caveat: This needs to be rewritten so that the normative language is separated from the example. And we should fix the typo also :) Thoughts? -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting 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