OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  Work items to be completed BEFORE we start OASIS processes

    Posted 02-04-2014 14:45
    XML grammar files Test RNG --> DTD and XSD transformation Process for adding OASIS copyright statement Markup for placeholder List of files that need the OASIS statement (all doctype shells + map.mod and topic.mod) Develop DITA 1.3 grammar files Incorporate DITA 1.2 errata Incorporate DITA 1.3 bug fixes Incorporate DITA 1.3 proposals Test DITA 1.3 grammar files Update style sheets Add processing for XML mention domain Add processing for RFC-2119 terminology Make necessary changes for 1.3 (footer files for CHM, readme for CHM) Correct processing for downloadable HTML ZIP Correct handling for @rev attributes Ensure that we can cross reference to a <dlentry> in PDF output Core editorial work Incorporate 1.3 content (Complete except for proposal #X) Edit 1.3 content Correctly markup RFC-2119 terminology Implement XML mention domain for archSpec Spec redesign and refactoring Rework attributes section of LangRef topics Design packages (work largely done, needs TC approval) Redesign content model information Generate content model content Rework LangRef to use keys in ideal way: Add key-definition maps Remove direct addressing from navigational maps Spec reviews How many? When? Back log for editorial work and spec redesign Spec clarifications and improvements (needs triaging) Serious content edit and review of the following subject areas in the archSpec: Terminology Keys Configuration, specialization, and constraints + related material in Non-normative section Serious content edit and review of the following subject areas in the LangRef Subject scheme Classification Add topic about classification domain to archSpec Implement XML mention domain Index archSpec topics Requested changes to spec Use ? notation instead of words to describe syntax more precisely (Jarno) All references in spec topics to specific elements should use @keyref (Jarno) Add glossary (Swope, other TechComm users) Volunteer roles to fill Maintain style sheets: Bob Thomas Review captain: [Robert: And can we get a fancy hat for the review captain?] RFC-2119 specialist Indexer? -- 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] Work items to be completed BEFORE we start OASIS processes

    Posted 02-04-2014 17:03
    I am interested in helping with the XML Grammar files, particularly with creating test content. Thanks and best regards, --Scott Scott Hudson         PELCO     by Schneider Electric         United States      Standards & Information Architect   Phone:   +1 970 282 1952     Mobile:   +1 720 369 2433      Email:   scott.hudson@schneider-electric.com Sites:   pdn.pelco.com , partnerfirst.pelco.com   On Feb 4, 2014, at 7:44 AM, Kristen James Eberlein < kris@eberleinconsulting.com > wrote: XML grammar files Test RNG --> DTD and XSD transformation Process for adding OASIS copyright statement Markup for placeholder List of files that need the OASIS statement (all doctype shells + map.mod and topic.mod) Develop DITA 1.3 grammar files Incorporate DITA 1.2 errata Incorporate DITA 1.3 bug fixes Incorporate DITA 1.3 proposals Test DITA 1.3 grammar files Update style sheets Add processing for XML mention domain Add processing for RFC-2119 terminology Make necessary changes for 1.3 (footer files for CHM, readme for CHM) Correct processing for downloadable HTML ZIP Correct handling for @rev attributes Ensure that we can cross reference to a <dlentry> in PDF output Core editorial work Incorporate 1.3 content (Complete except for proposal #X) Edit 1.3 content Correctly markup RFC-2119 terminology Implement XML mention domain for archSpec Spec redesign and refactoring Rework attributes section of LangRef topics Design packages (work largely done, needs TC approval) Redesign content model information Generate content model content Rework LangRef to use keys in ideal way: Add key-definition maps Remove direct addressing from navigational maps Spec reviews How many? When? Back log for editorial work and spec redesign Spec clarifications and improvements (needs triaging) Serious content edit and review of the following subject areas in the archSpec: Terminology Keys Configuration, specialization, and constraints + related material in Non-normative section Serious content edit and review of the following subject areas in the LangRef Subject scheme Classification Add topic about classification domain to archSpec Implement XML mention domain Index archSpec topics Requested changes to spec Use ? notation instead of words to describe syntax more precisely (Jarno) All references in spec topics to specific elements should use @keyref (Jarno) Add glossary (Swope, other TechComm users) Volunteer roles to fill Maintain style sheets: Bob Thomas Review captain: [Robert: And can we get a fancy hat for the review captain?] RFC-2119 specialist Indexer? -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ --------------------------------------------------------------------- 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] Work items to be completed BEFORE we start OASIS processes

    Posted 02-04-2014 17:10
    Scott, What I need is a set of documents that does the following: - Tests each OASIS-defined shell for each of the RNG, DTD, and XSD versions. - For each shell, at least one document that reflects every allowed element type (unless it's simply impractical to do so, but it shouldn't be impossible) and, to the degree we can, each defined value for enumerated attributes, or at least representative values where the spec does not define a closed enumeration. - For each shell, at least one document that is invalid that verifies that the shell correctly identifies invalid documents, e.g., a concept with text directly within <conbody> It would be ideal to have a set of documents for DITA 1.2 that tests our 1.2 baseline and then a corresponding set of documents that tests the new 1.3 vocabulary. Note that these are tests simply of validation of markup, not tests of functionality, which would be a separate set of tests (e.g., tests for key scopes, branch filtering, etc.). I will coordinate with Kris to set up an area in the OASIS SVN repository for managing our testing stuff. Cheers, E. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com On 2/4/14, 11:02 AM, "Hudson, Scott" <Scott.Hudson@schneider-electric.com> wrote: > > > >I am interested in helping with the XML Grammar files, particularly with >creating test content. > >Thanks and best regards, > >--Scott >Scott Hudson PELCO by > Schneider Electric United States Standards & Information >Architect >Phone: +1 970 282 1952 Mobile: +1 720 369 2433 Email: >scott.hudson@schneider-electric.com >Sites: pdn.pelco.com < http://pdn.pelco.com > , >partnerfirst.pelco.com < http://partnerfirst.pelco.com > > > > > > > > > > > > > > >On Feb 4, 2014, at 7:44 AM, Kristen James Eberlein ><kris@eberleinconsulting.com> wrote: > > > >XML grammar files > >* Test RNG --> DTD and XSD transformation >* Process for adding OASIS copyright statement > >* Markup for placeholder >* List of files that need the OASIS statement (all doctype shells + >map.mod and topic.mod) > > > >* Develop DITA 1.3 grammar files > >* Incorporate DITA 1.2 errata >* Incorporate DITA 1.3 bug fixes >* Incorporate DITA 1.3 proposals > > > >* Test DITA 1.3 grammar files > >Update style sheets > > >* Add processing for XML mention domain >* Add processing for RFC-2119 terminology > >* Make necessary changes for 1.3 (footer files for CHM, readme for CHM) >* Correct processing for downloadable HTML ZIP > >* Correct handling for @rev attributes >* Ensure that we can cross reference to a <dlentry> in PDF output > > > >Core editorial work > >* Incorporate 1.3 content (Complete except for proposal #X) > >* Edit 1.3 content >* Correctly markup RFC-2119 terminology >* Implement XML mention domain for archSpec > > > >Spec redesign and refactoring > > >* Rework attributes section of LangRef topics >* Design packages (work largely done, needs TC approval) > >* Redesign content model information >* Generate content model content >* Rework LangRef to use keys in ideal way: > >* Add key-definition maps >* Remove direct addressing from navigational maps > > > > > >Spec reviews > > >* How many? When? > > >Back log for editorial work and spec redesign > > >* Spec clarifications and improvements (needs triaging) > >* Serious content edit and review of the following subject areas in the >archSpec: > >* Terminology > >* Keys >* "Configuration, specialization, and constraints" + related material in >"Non-normative" section > > > >* Serious content edit and review of the following subject areas in the >LangRef > >* Subject scheme >* Classification > > > >* Add topic about classification domain to archSpec > >* Implement XML mention domain >* Index archSpec topics > > >Requested changes to spec > > >* Use ? notation instead of words to describe syntax more precisely >(Jarno) > >* All references in spec topics to specific elements should use @keyref >(Jarno) > >* Add glossary (Swope, other TechComm users) > > > >Volunteer roles to fill > > >* Maintain style sheets: Bob Thomas > >* Review captain: [Robert: And can we get a fancy hat for the review >captain?] > >* RFC-2119 specialist >* Indexer? > > > > >-- >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) > > > > > > >______________________________________________________________________ >This email has been scanned by the Symantec Email Security.cloud service. >______________________________________________________________________ > >--------------------------------------------------------------------- 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 >< https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > >


  • 4.  Re: [dita] Work items to be completed BEFORE we start OASIS processes

    Posted 02-04-2014 17:28
    Sounds great! That’s exactly what I’d like to help contribute. Just let me know where I can start putting these and I’ll get started. Thanks and best regards, --Scott Scott Hudson         PELCO     by Schneider Electric         United States      Standards & Information Architect   Phone:   +1 970 282 1952     Mobile:   +1 720 369 2433      Email:   scott.hudson@schneider-electric.com Sites:   pdn.pelco.com , partnerfirst.pelco.com   On Feb 4, 2014, at 10:08 AM, Eliot Kimber < ekimber@rsicms.com > wrote: Scott, What I need is a set of documents that does the following: - Tests each OASIS-defined shell for each of the RNG, DTD, and XSD versions. - For each shell, at least one document that reflects every allowed element type (unless it's simply impractical to do so, but it shouldn't be impossible) and, to the degree we can, each defined value for enumerated attributes, or at least representative values where the spec does not define a closed enumeration. - For each shell, at least one document that is invalid that verifies that the shell correctly identifies invalid documents, e.g., a concept with text directly within <conbody> It would be ideal to have a set of documents for DITA 1.2 that tests our 1.2 baseline and then a corresponding set of documents that tests the new 1.3 vocabulary. Note that these are tests simply of validation of markup, not tests of functionality, which would be a separate set of tests (e.g., tests for key scopes, branch filtering, etc.). I will coordinate with Kris to set up an area in the OASIS SVN repository for managing our testing stuff. Cheers, E. -- Eliot Kimber Senior Solutions Architect Bringing Strategy, Content, and Technology Together Main: 512.554.9368 www.reallysi.com www.rsuitecms.com On 2/4/14, 11:02 AM, Hudson, Scott <Scott.Hudson@schneider-electric.com> wrote: I am interested in helping with the XML Grammar files, particularly with creating test content. Thanks and best regards, --Scott Scott Hudson      PELCO  by Schneider Electric      United States     Standards & Information Architect Phone: +1 970 282 1952    Mobile: +1 720 369 2433   Email: scott.hudson@schneider-electric.com Sites: pdn.pelco.com <http://pdn.pelco.com> , partnerfirst.pelco.com <http://partnerfirst.pelco.com> On Feb 4, 2014, at 7:44 AM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote: XML grammar files * Test RNG --> DTD and XSD transformation * Process for adding OASIS copyright statement * Markup for placeholder * List of files that need the OASIS statement (all doctype shells + map.mod and topic.mod) * Develop DITA 1.3 grammar files * Incorporate DITA 1.2 errata * Incorporate DITA 1.3 bug fixes * Incorporate DITA 1.3 proposals * Test DITA 1.3 grammar files Update style sheets * Add processing for XML mention domain * Add processing for RFC-2119 terminology * Make necessary changes for 1.3 (footer files for CHM, readme for CHM) * Correct processing for downloadable HTML ZIP * Correct handling for @rev attributes * Ensure that we can cross reference to a <dlentry> in PDF output Core editorial work * Incorporate 1.3 content (Complete except for proposal #X) * Edit 1.3 content * Correctly markup RFC-2119 terminology * Implement XML mention domain for archSpec Spec redesign and refactoring * Rework attributes section of LangRef topics * Design packages (work largely done, needs TC approval) * Redesign content model information * Generate content model content * Rework LangRef to use keys in ideal way: * Add key-definition maps * Remove direct addressing from navigational maps Spec reviews * How many? When? Back log for editorial work and spec redesign * Spec clarifications and improvements (needs triaging) * Serious content edit and review of the following subject areas in the archSpec: * Terminology * Keys * Configuration, specialization, and constraints + related material in Non-normative section * Serious content edit and review of the following subject areas in the LangRef * Subject scheme * Classification * Add topic about classification domain to archSpec * Implement XML mention domain * Index archSpec topics Requested changes to spec * Use ? notation instead of words to describe syntax more precisely (Jarno) * All references in spec topics to specific elements should use @keyref (Jarno) * Add glossary (Swope, other TechComm users) Volunteer roles to fill * Maintain style sheets: Bob Thomas * Review captain: [Robert: And can we get a fancy hat for the review captain?] * RFC-2119 specialist * Indexer? -- 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) ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ --------------------------------------------------------------------- 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 <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php> ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________