We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byCharity Gibbens
Modified about 1 year ago
XML Done Well - The eXtensibility Manifesto A Blueprint for XML Implementation © 2005-2006 aXtive Minds & Allette Systems XML
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 2 Problems with XML Development Cost overruns / failed implementations Complexity is too expensive Lack of formal methodologies Lack of best practices to learn from Reinventing implementation strategies
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 3 Problem 1 – Too Many Rules Excessively constrained structures enforced at the expense of usability increase development and maintenance, and therefore risk, especially for new implementations. New implementer of XML identifies and enforces excessive structural constraints Hopes to achieve highly structured and regular data Produces a untenable and user-hostile data model Extended production schedules with no added value
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 4 Problem 2 – Paved Cow Path Data model designed to closely to the needs of a single intended use limits repurposing for other uses. Data model enforces rules specific to printed manuals in a way that makes it difficult for databases, Web or other uses not well supported Increased development and data transformation costs and schedules Missed business opportunities
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 5 Problem 3 – Clever Trevor Excessive use of Schema modularity makes data model opaque, where a simpler structure would be more transparent, easier to maintain, and require less time to develop Clever schema designer uses parameter entities or schema modules in a manner that shows off their ability instead of improving leveragability of the data model, The data module produced is excessively opaque, difficult to work with, and expensive and risky to implement
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 6 Problem 4 – Potato vs. Patahto Inconsistent naming conventions used throughout data model and programming development increases development time and risk and reduces ability to leverage reusable components. Sloppy naming and module design reduce reusability of schema components and processing applications Reduced ease of use by other developers or users Increased implementation investment, schedules and risk Potential confusion for users and developers
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 7 Problem 5 – Maybe Someday… Proactive development for all potential contingencies regardless of their likelihood increases risk and development Schema design team creates elements that have low value or low probability of ever being encountered A misguided attempt to be thorough, increasing development Confusion to users having to select from list of ambiguous elements Effective data sampling and prioritized requirements can focus development investment on requirements needed upfront Many specific elements could be more easily managed as a single class of element
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 8 Problem 6 – Hammer & Bolt Misapplication of tools to tasks or structures for which they were not designed E.g., Developer who writes their own XML parsing function in a common scripting language might be better off getting training and using XSLT, XQuery or some other tool with XML capabilities built in Increases development and risk, whereas effective use of most appropriate tools and standards for their intended use improve success and schedule of projects
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 9 Learning from Other Development Areas Why doesn't XML have the same support and maturity models as other types of development Relational DBMS OO Development UML J2EE
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 10 Different Roles / Different Needs How do different types of people learn how to do their role in XML development? System Analyst Data Modelers Project Managers Managers Programmers looking for best practices
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 11 Objectives To create guidelines and a methodology to: Improve predictability and success rates of XML implementations Improve quality of data models, tools, etc. Stream line development and production timelines Accelerate maturation of developer, manager, and user skills Create a "checklist" for Efficient XML development Make XML simpler to do
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 12 The eXtensibility Manifesto Several experienced XML developers and project leaders seek to design a methodology for XML development Focuses on delivering XML in the simplest form which meets targeted business requirements Aims to reduce risk and complexity of XML applications The product of this loose consortium is the eXtensibility Manifesto 10 Guiding Principles for Effective XML Development Follow on activity
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 13 Philosophy "Everything should be made as simple as possible, but not simpler!" -- Albert Einstein Investment increases with complexity, but benefits may not! Each XPath node in a data model costs something to implement and should only be included if warranted by the potential benefit it provides. If it's not Efficient XML, it's Deficient XML!
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 14 Guiding Principles 1.Schemas and data have a mutual obligation to the simplest structure possible, achievable by continual reassessment of the two by their creators and rigorous justification for every modification. 2.Efficient XML development produces the necessary functionality and benefits with the minimum investment. 3.Design of a data model focuses on all stakeholders' requirements for the data. 4.Requirements are prioritized to guide design and development and address known issues and requirements, not hypothetical possibilities. 5.Effective sampling and analysis upfront reduces risk and improves implementation schedules.
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 15 Guiding Principles 6.Designs or components are not reinvented, but rather are leveraged where possible. 7.Consistency and clarity of practices remove ambiguity and enable designs, applications, and data to be leveraged to reduce investment. 8.Manageable iterative releases done over time focus on most important benefits first. 9.Documentation of design and components is always done but must be simple yet efficient and feasible to produce and maintain. 10.A clearly articulated methodology improves developers understanding and participation, accelerates development and reduces risk.
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 16 Organizers Nick Carr, Allette Systems Marcus Carr, Allette Systems Rick Jelliffe, Topologi Dale Waldt, aXtive Minds Priscilla Walmsley, Datypic Devan Shepherd, XMaLpha Technologies Marion Elledge, IDEAlliance
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 17 Next Steps Publish eXtensibility Manifesto & Guiding Principles Organize to continue this work Refine Guiding Principles Develop Efficient XML Methodology Provide Web site & community tools Develop papers & articles Organize training
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 18 For More Information… Web Site http://extensibilitymanifesto.org Contacts: Dale Waldt dale@aXtiveminds.comdale@aXtiveminds.com Nick Carr firstname.lastname@example.org@allette.com.au
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 19 XML Done Well, © 2006 aXtive Minds XML Best Practices book written by leading XML developers Scheduled to be Published September 2006 and available at Open Publish 2006 Features: The Extensibility Manifesto XML Governance / Development Methodology Effective Schema & DTD Design Effective XSLT & Application Design Quantifying XML Effectiveness Degrees of Validation Implementation Case Studies Etc.
The eXtensible Manifesto – Philly XML User Group - June 2006 © aXtive Minds and Allette Systems Page 20 Open Publish 2006 Conference on Open Standards & Technology in Publishing September 27 – 29, Baltimore Form more info & Call for Papers: http://open-conferences.com/baltimore
Fundamentals of Information Systems, Second Edition 1 Systems Development Chapter 8.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
CS 360 Lecture 3. The software process is a structured set of activities required to develop a software system. Fundamental Assumption: Good software.
Smart Home Technologies System Engineering. System Engineering in Intelligent Environments Intelligent Environments are complex systems consisting of.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Software Project Planning CS470. What is Planning? Phases of a project can be mostly predicted Planning is the process of estimating the time and resources.
Project management Project manager must; Plan the Project: Very simply stated, a good plan saves time and reduces the cost of the project. Or, alternatively.
Principles of Information Systems, Seventh Edition2 Effective systems development requires a team effort from stakeholders, users, managers, systems development.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Project management Topic 1 Introduction. Why do projects fail? Business case is not valid Lack of quality control –Product not acceptable Outcomes not.
Data Gathering Techniques 27 th February Data Gathering Techniques System requirements specify what the system must do or what property or quality.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
UI Standards & Tools Khushroo Shaikh. Outline What is UI? Why we need standard? History of UI Standard. A Small Example. Types of Standards. How to build.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Setting up a Hyperion Center of Excellence Case Study at Plantronics By
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management What is Risk Management Risk Management Strategies Software Risks.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Principles of Information Systems, Sixth Edition Systems Investigation and Analysis Chapter 12.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
1 Software Process and Product Metrics CIS 375 Bruce R. Maxim UM-Dearborn.
Design and Planning Or: What’s the next thing we should do for our project?
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
Copyright 2010, The World Bank Group. All Rights Reserved. Testing and Documentation Part II.
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management What is Risk Management Risk Management Strategies Software Risks.
Principles of Information Systems, Sixth Edition 1 Systems Investigation and Analysis Chapter 12.
Copyright 2005 Digital Enterprise Research Institute. All rights reserved. Towards Translating between XML and WSML based on mappings between.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
“Content Management and the need for change in Technical Communication.” Written by: Scott P. Abel Presented by: Ayodele Smith.
Quality of Information systems. Quality Quality is the degree on which a product satifies the requirements Quality management requires that : that requirements.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
0 Content Management and the Need for Change in Technical Communication Written by: Scott P. Abel 20 June 2007 Nick Savillo ENG 393.
1 Knowledge & Knowledge Management “Knowledge is power” to “Sharing K is power” Yaseen Hayajneh, PhD.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Name Project Management Symposium June 8 – 9, 2015 Slide 1 Susan Hostetter, Reed Livergood, Amy Squires, and James Treat 2015 Project Management Symposium.
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Investigation and Analysis Chapter 12.
Systems Analysis – Analyzing Requirements. Analyzing requirement stage identifies user information needs and new systems requirements IS dev team.
1 Requirements Engineering for Agile Methods Lecture # 41.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Now what? 1. I have short-listed projects I am interested in I know the types of projects I would like to pursue I have an idea of the resources.
Sharif University of Technology Session # 4. Contents Systems Analysis and Design Sharif University of Technology MIS (Management Information System),
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
UNCERTML - DESCRIBING AND COMMUNICATING UNCERTAINTY WITHIN THE (SEMANTIC) WEB Matthew Williams
1 Software Process Models-ii Presented By; Mehwish Shafiq.
© 2017 SlidePlayer.com Inc. All rights reserved.