[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: OASIS DITA Technical Standards Subcommittee - Meeting Minutes
Hi everyone, Sorry I was unable to make the meeting this afternoon - it sounds like good progress was made! I do have to write with my TC Admin hat on; we need to keep this work within the TC and that means that only those individuals who are OASIS members and have joined both the DITA TC and this subcommittee as "members" are able to participate; those who aren't members should follow the work via the email archives, wiki pages, and other publicly-accessible resources and should not be copied directly. If anyone needs assistance with: - becoming an OASIS member, - getting an OASIS user account, or - joining the TC Please send me a note and I'll be happy to assist. Regards, Mary > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Tuesday, December 16, 2008 5:21 PM > To: Rick Heil > Cc: Bill Trippe; Brian R Bokor; dcarlson@xmlmodeling.com; dita- > techstds@lists.oasis-open.org; Donald Buddenbaum; Mary McRae; Rick > Heil; Rich Rogers; tdeakins@amcanet.com > Subject: Re: OASIS DITA Technical Standards Subcommittee - Meeting > Minutes > > Thanks for taking the minutes, Rick. > > I've updated the Requirements and Use Cases page with information about > the DITA and OASIS templates (hoping that Mary or Robin can correct or > supplement the OASIS template description): > http://wiki.oasis-open.org/dita/techstdsRequirements > > Thanks - > > Robert D Anderson > IBM Authoring Tools Development > Chief Architect, DITA Open Toolkit > > > > Rick Heil > <rheil@amcanet.co > m> > To > Mary McRae > 12/16/2008 04:55 <mary.mcrae@oasis-open.org>, > PM "dcarlson@xmlmodeling.com" > <dcarlson@xmlmodeling.com>, > "dita-techstds@lists.oasis- > open.org > " > <dita-techstds@lists.oasis- > open.org > >, Rick Heil > <rheil@amcanet.com>, > "tdeakins@amcanet.com" > <tdeakins@amcanet.com>, Brian R > Bokor/Raleigh/IBM@IBMUS, Donald > Buddenbaum/Durham/IBM@IBMUS, > Rich > Rogers/Raleigh/IBM@IBMUS, Robert > D > Anderson/Rochester/IBM@IBMUS, > Bill > Trippe <bill@gilbane.com> > > cc > > > Subject > OASIS DITA Technical Standards > Subcommittee - Meeting Minutes > > > > > > > > > > > Hello all, > > Here are my rough meeting minutes from today’s somewhat abstract > conversation about what we are hoping to do and how to get there. We > made good progress indeed. If my notes are missing anything or anyone > on the call should you wish to elaborate – please do! > The key outcome was a path forward – Robert is setting up a wiki page > to begin documenting the components/parts of a specification starting > with the general OASIS spec template and then adding the actual DITA > spec to that analysis. The expectation is by creating a content list of > all the elements of several specs we should be able to tease out a > common pattern we can build a requirements and potential > specialization(s) around. > > Cheers, > Rick > > ----------------- > DITA Meeting Notes… > > Robert took attendance and posted to the OASIS site/ Approval of > minutes from last meeting – motion to approved, seconded, and approved. > > New Business Discussion > > Discussed getting our arms around scope and approach to take in > defining a DITA technical toolkit Initial core focus is on the > following spec deliverable “forms” > UML Class Diagrams and potentially other UML artifacts (like > collaboration diagrams, etc.0 > XSD Schema (XSD) especially for defining message detail/structure > DITA for narrative portion specs primarily for human readable > content, the ‘meaning’ metadata like definition, description, > annotation, aliases and so forth. > > Ideally would like to be able to achieve a single normative source so > every characteristic of a specification is defined only once in one > places then reference from there – e.g. a tag/element name should be > defined in one place to avoid misspelling > > Probably not possible to have a single source, just one tool, but > rather develop a means of easily interchanging information between them > – thus DITA becomes the means of defining much of the human consumable > ‘meaning’ > data and the structure for defining other metadata needed for message > specification, programming language, etc. > > Possible similar to HL7 model – where they use UML, XSD and other tools > with transformation between them. > > Idea of going between them – is it a transform back and forth (each > their own domain with translation0 or could DITA be the “Esperanto’ > universal second language of every specification??? > > > What are the parts of a spec that we need to capture? > - Narrative > o Information about metadata around the spec (authors, > version, history) > § Bookmap > o Resources > o Errata > o Requirements Section > o Use Cases (based on UML Use Cases) > o Diagrams (based on UML Class Diagrams) > - Schema and models for messages, data model > o Detailed description of a message > o API ref may be a starting point. > - Generating java APIs or other coding specs > - Specializations for web services; WSDL, etc. > - Other specializations that are common to spec > definition > > Goal of having a single normative spec, if achievable > > Idea to start with the narrative specialization > Let’s use the actual DITA spec as an example, how do we > document DITA using DITA > Get DITA working then look at an additional spec or 2, > 3 and fit them in… > Abstract out the structures they use > Look at the ISO standards and others > later > Create a spreadsheet looking at a number of specs? > Decided to instead use a more collaborative approach – use the wiki to > create table(s) of specification elements and see if we can tease out a > common structure sufficient for all/any. > Begin with the ‘master OASIS Specification template’ > and see what it defines, then DITA, then a few others. > > Are we saying the DITA becomes not only a publishing view of the > semantics supplementing the technical semantics of a UML model (for > example). How does it relate to a model driven architecture or similar > approach, can we tie them together? Is it also right to think of it > being an interchange format between other specifications? Providing > close equivalence between the way information moves between systems. > The DITA content model is more human readable form (more about > ‘meaning’). > > Objective of identifying the common intersection between the human > readable semantics with the machine semantics artifacts > > > Richard J. Heil Jr. CLU, ChFC • Practice Director • Abraham, > McDonald and Associates > Cell: (435) 513-0460 • Office: (435) 578-1297 rheil@amcanet.com • > IM Yahoo: rheil29, AOL: rheil260 • Linked In: > http://www.linkedin.com/in/rickheil > (Embedded image moved to file: pic11356.gif)Think before you > print.Think before you print.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]