1 / 45

Presentation to Dita TC R&D work of convergence between S1000D and Dita

Presentation to Dita TC R&D work of convergence between S1000D and Dita. Jean-Jacques Thomasson representing the French Group working on S1000D and DITA Company Euriware (Areva) July 2012. Introduction. Members of the S1000D-DITA initiative WG. Guillemette Borrel :

odelia
Download Presentation

Presentation to Dita TC R&D work of convergence between S1000D and Dita

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Presentation to Dita TCR&D work of convergence between S1000D and Dita Jean-Jacques Thomasson representing the French Group working on S1000D and DITACompany Euriware (Areva) July 2012

  2. Introduction

  3. Members of theS1000D-DITA initiative WG Guillemette Borrel : • Technical Mgr of Information Management Dpt at LGM (Consulting Grp) • National recognize expert in Data Format Exchange : Documentation (S1000D/DITA), PLM, Logistic Data (S3000L, 1388-2B), PLCS Michel Domeon : • Technical publications manager at Dassault-Aviation • 2002-2010 involvedfrom 94 as chair and co chair within the S1000D management groups (EPWG, TPSMG, SteeringCommittee) Nicolas Dupuy : • S1000D Senior Consultant at PTC • Co-chairman of S1000D EPWG group since 2006 and GIFAS representative Philippe Zingoni • Business DeveloperatAntéaafter 10 years of CTO • a well-known French reseller of Adobe FrameMaker, PTC IsoDraw and Lattice 3D • 10 years of work on S1000D standardization (Expert in CCMS & CGM) Jean-Jacques Thomasson • Detailedresumehereafter

  4. Resume and publications 1984  1989 DCF/GML & DB2 developer (DassaultSystème) 1989  1997 Pre-sales & services manager at InterleafFrance and SGML/XML evangelist for Europe 1997  2006 Technical Director at Nagora then Sonovision-Itep (misc. publications on XML) 2006  2009 Consultant for Total (EDMS for Worldwide Operations) 2010  EDMS Senior expert at Euriware [Areva] 2002 2003 2006 1959 1984 2009 2012 Life with ML as … Mother Language Life with ML as GMLSGMLXML

  5. Resume and publications Member of the French SGML UG (1993-1998) President of XML-France (2001-2003) Contributions to standards through translations • W3C XSLT, DOM, XPath, XML Schema (1998-2002) • IETF WebDAV (2001) • XML Topics Maps (2003) • Other translation : O’Reilly XML Schema (2002) Books : • Schémas XML (Eyrolles – 2002) • Modélisation XML (Eyrolles – 2006) • 7 articles for Gartner Group (2003-2005) R&D work : • RDM Store project (1993) • Complete re-design of the S1000D XML Schemas (2005 – 2006)

  6. The growth of a model : the S1000D case 2012 S1000D v4 Adopted worldwide 2007 S1000D v3 ATA 2200 Air Transport Association AIA ASD S1000D v2 2003 Aerospace industries Association Air - Land - Sea AECMA 1000D v1 Land & sea 1989 Military Aircraft 1984 7 European countries

  7. The growth of a model : the S1000D case Breakthrough with a new meta-model 2012 S1000D v4 Adopted worldwide 2007 S1000D v3 ATA 2200 Air Transport Association AIA ASD S1000D v2 2003 Aerospace industries Association Air - Land - Sea AECMA 1000D v1 Land & sea 1989 Military Aircraft 1984 7 European countries

  8. The growth of a model : the S1000D case

  9. S1000D : Initial problem reminder • The natural growth of S1000Ds through the ages • Business view: • How to mix different ways of handling of applicability and techdoc organization? • Ease and even feasibility of the standardization work • Acceptance by the users (current members and newcomers) of the resulting standard • Technical concerns: • Hierarchical or logical chunking ? • Why validity of sub-schemas is important ? • What means validity ? • What is the concept of fractal validity ? • How to maintain consistency between DTDs and XML Schemas versions ?

  10. DITA : Initial problem reminder A tentative started in 2009 of R&D work to clean up the XML Schemas • 12/2009 initial objectives • Each sub-schema must be a valid schema by itself, • Groups of element can not be derived, • Restrictions must be valid derivation of the parent object. • Recursive models which indirectly expand the parent model are forbidden by XML Schema unless there is a formal extension. • Irregular structures such as the "fn.class" model which is mixing at the same level text, inline data elements, structural elements and pure structural elements. It mixes in line elements and main structural elements such as paragraphs. Such models lack of flexibility and possibilities of managing small chunks of information are limited. This question concerns the possibility of considering that specializations address changes in the main structure while domains address the question of inline semantics elements. • The 1.2 schemas make : • Impossible individual check up / control / change • Hard the sharing of sub schemas between different specializations • Extensibility complex

  11. Proposed solution for DITA

  12. DITA : proposed solution • A complete re writing of the XML schemas • New meta-model respecting the Spec and DITA original extensibility mechanisms • A UML representation which could look complex but the concrete implementation is *very* simple with only 5 basic <include>.

  13. DITA : proposed solution One core package which has no link to other packages

  14. DITA : proposed solution Each specialization has only one <include> to other packages : one link to domain(s) (through which core elements will be included)

  15. DITA : proposed solution At least, each domain has only two links to the [core] package

  16. DITA : proposed solution Same model is used for <dita> root element : it contains only one link to CRTTs and alternatively one to domains unused by CRTTs

  17. DITA : proposed solution Finally, this model ideally combines : • The logic of XML schema • A « logical » physical hierarchy making a clear border between a core set of elements, the domains’ elements and the specialization • This model will force the future changes of the model to be regular wherever they will be done : • At the core level • At the domain level • At the specialization level

  18. Joining DITA and S1000D

  19. Joining S1000D and DITA:The business cases Interchange of data between aerospace/defense and other manufacturing companies • To avoid conversions for sub contractors facing multi-standards requirements • Particularly true for software components used in weapon and flight systems Use of DITA maps or S1000D PM to publish both DITA and S1000D content • Use of DITA maps features, such as navigational links (no equivalent in S1000D) • Use of applicability filtering at the publication level (both DITA & S1000D) • Use the DITA OT to publish (when S1000D publication process is expensive) Reuse mechanisms • DITA : General reuse of any piece of information through conrefs • S1000D : reuse of common components (Common Information Repository)

  20. Joining S1000D and DITA:The business cases Easier implementations for decreasing the acquisition cost of the technology • Creation of software solutions for both S1000D and DITA • Common frameworks A « Basic » structure • Many discussions in S1000D French standardization about « S1000D Light » • This concept should be used to define a core architecture that could be the base for advanced specializations Flexibility • S1000D looking for new directions to increase the flexibility of the models

  21. Assembling or building complex schemas ? 2014 / 2015 S1000D v5 & DITA v2 2012 S1000D v4 2010 DITA 1.2 2007 S1000D v3 DITA 1.1 2007 DITA 1.0 2005 2003 S1000D v2 2001 1989 1000D v1 1984

  22. Management of very big models • S1000D : • 1056 elements (945 complex, 111 simple) • 372 attributes • 149 simple types and 884 complex types • DITA : • 848 éléments (751 complex, 97 simple) • 276 attributes • 111 simple types and 726 complex types • TOTAL : • ≈ 2000 éléments • ≈ 650 attributes • ≈ 250 simple types and 1600 complex types • It is mandatory to establish communalities to decrease the cost of implementation and maintenance of each

  23. Management of very big models • When merging schemas or grammar, the designer needs to : • Know if the name is already in use • If yes : • what for ? • In the same domain or not ? • Are the types compatible or not ? • Know at which level of the schema hierarchy the new component must be designed • Core level for an impact on the entire standard : role of DITA TC • Specialization level for an impact on one business : role of business groups • Inline semantics for a transverse availability : role of DITA TC or business group • Know the exact impact of one modification : • On the structures • On one particular business • But also on documentation

  24. Hierarchical versus logical chunking(of schemas) • Here comes / arises the problem of the logic which is behind the meta-model of the schemas • SGML was allowing physical chunking of DTDs into pieces • XML Schema bans that, it only allows for logical chunking • Relax NG is so said « a pure hierarchical model »

  25. Hierarchical versus logical chunking(of schemas) Physical cut up/chunking Logical approach Authorized in DTDs through the mechanism of SYSTEM entities which does not exist in XML Schema Controlled by manual design only in DTDs Strictly enforced with XML Schema

  26. Hierarchical versus logical chunking(of schemas) Physical chunking possibily leads to mess :

  27. Hierarchical versus logical chunking(of schemas) • An XML Schema can be a tree of valid sub and sub-sub schemas: • Where any of the sub-schemas can itself be the root of a tree of schemas • And any of the sub-schemas can include any other sub-sub-schemas … An XML Schema An XML Schema containing elements Definitions or groups of An XML Schema containing attributes Definitions or groups of An XML Schema containing complex types definitions An XML Schema containing simple types definitions Any valid XML Schema

  28. Hierarchical versus logical chunking(of schemas) • There is no real concept of hierarchy at the meta-schema level: • One “sub schema” can itself be the root and the root be, at some time, a sub-schema • In one word : there is no concept of DOCTYPE. No start, no end. An XML Schema An XML Schema containing elements Definitions or groups of An XML Schema containing attributes Definitions or groups of An XML Schema containing complex types definitions An XML Schema containing simple types definitions Any valid XML Schema

  29. Hierarchical versus logical chunking(of schemas) • There is no real concept of hierarchy at the meta-schema level: • Set of schemas which are libraries of components / objects • Schemas wearing the business logic An XML Schema An XML Schema containing elements Definitions or groups of An XML Schema containing attributes Definitions or groups of An XML Schema containing complex types definitions An XML Schema containing simple types definitions Any valid XML Schema

  30. The design can improve: • Readiness • Flexibility • Validity, which will facilitate: • Implementation of new mechanisms (Example : internal and external mechanism of applicability inherited from ATA) • Use of XML Schema conforming software tools • Better separation between business logic and technical structures • “Schemas as a Lego” • Development of modular style sheets in line with modular schemas • Control, maintenance and documentation : • Avoiding duplication of same types • Producing dictionaries of models, elements, attributes and types (already available on S1000D side)

  31. Be concrete : • The S1000D-DITA working group is currently working on:

  32. Be concrete : • 6 Proofs of concept have been done • POC 1 : addition of a new domain in technicalContent which modifies <keyword> and limits the types of topics to only <reference> • POC 2 : limitation to only <reference> and domain poc1-d • POC 3 : addition of the new type of topic proceed by duplication of an existing type of topic. • POC 4 : addition of the entire set of S1000D elements (but v2.3 version) • POC 5 : addition of the latest v4 elements of S1000D, name dmodule is used instead of proceed, one same instance is made of DITA topics and S1000D modules. • POC 5 RNG : POC 5 converted to RNG • POC 6 : Reorganization of the physical model and extension of the study to publication modules : pm, map and bookmap. Each can now be a mixture of any others. • Other studies • Business case and positioning • Relax NG

  33. POC made with RNG We did a RNG version of the XML schema Two problems were found : • No recursive include : • Meta model of Relax NG is strictly hierarchical making impossible the concept of libraries of schema components • Root element is mandatory • <NotAllowed> is sued to avoid the problem • It makes individual testing of sub schemas (grammars) impossible • For example : reference.mod.rng • Using <notAllowed> and @combine=“choice” changes a bit the concept of validation of the sub-schemas

  34. POC made with RNG example : reference.mod.rng Grammar :

  35. POC made with RNG Case by case testing of parts of a grammar such as reference.rng is hard or even impossible : • Producing the instance reduced to one particular element is not possible • This occurs with any of the sub-schemas of the RNG version On Schemas side, any element can be individually tested: • Since Schema are « really » (not artificially) valid • No Doctype or equivalent : Any element at any time can be the root element of an instance • Design based on testing becomes very easy • New proposals can be easily prototyped for discussions • Training and documentation are much more simple • Development time is concentrated on the design of the content model rather than spent in lexical and consistency problems • Focus is made on having a coherent catalog of components which are then easy to control, implement, test and document

  36. POC made with RNG Example with the elements of topic reference:

  37. POC made with RNG Testing can be indifferently made at the root element level <reference> and at anay sub-level, as here after with sub-element <propdesc>:

  38. POC made with RNG And here is the test from te root element:

  39. POC made with RNG Or any of the elements part of that branch of the structure (abstract for example)

  40. POC made with RNG If you want to test elements defined by reference.mod.rng, then the test is limited You need to use reference.rng which only allows a test from the root element <reference>

  41. POC made with RNG No document editor supporting natively Relax NG: • FrameMaker : no • PTC Arbortext : no • XML Author (Word) from Quark : no Support by professional wyziwyg structured editors is a major concern: • Use of additional module such as simplified english • Paper oriented presentation still requires precise positioning and interactive control of layout • Revision management, dictionaries, layout of tables… • Integration with Techdoc Mgt systems, PLM, EAM and so ….

  42. Conclusion • Respecting the intrinsic logic of XML Schema is a *secure* way for extending the models to cover a larger spectrum of business needs • Our R&D work shows that the new model can join: • The physical representation is logical for a human being. Moreover, the tree of folders is not rigid but is highly flexible: the sub-folders or the contained sub-schemas can be moved all around if necessary. • The logical model not only sticks to XML Schema meta-model but also has a sense for both humans (it is easy to understand) • It applies the concept of modularization not only at the information level but also at the schemas’ level: • Fractal tree of schemas capable of growth like a natural tree • Authorizing the management of very small pieces of information • Probably extendable to concept of modular stylesheets

  43. Conclusion • With the proposed approach, version 2 of DITA can immediately embrace the Aerospace& Defence market of Logistics Support. • On his side, S1000D can take benefit from the DITA experience in software documentation. • Instead of reinventing the wheel, S1000D and DITA groups can focus on the software tools and toolbox surrounding the standards for a better ratio efficiency / cost.

  44. Demo

  45. Questions Jean-Jacques Thomasson Euriware

More Related