[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Conformance and interoperability
I agree with a "must" in a conditional construction like this: "To support extensibility and pluggability, DITA requires..." But now that I understand a bit more about conformance clauses - http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html - this kind of situation should be handled by defining different "conformance targets" - and this is especially important now that we've agreed to merge the language and the architectural specs into a single document. It seems to me that the two targets we have are: 1. A DITA-conformant document 2. A DITA-conformant customization (or extension, if you prefer) A particular implementation could then decide to conform to #1 - but not to #2. #2 is where we differ from most other OASIS specs, I think - which tend to focus on defining a standard vocabulary merely, and leave the implementation that produces conforming documents more up in the air. On the other hand, since 1.1 I've done a lot of research into "design patterns" - indeed, I'm working up a proposal right now for DITA Europe about some "Writing Patterns" we've implemented at Oracle using a DITA customization - and I think we are misusing the term in our specs. What we're describing in the architectural spec isn't a design pattern - it's a DTD coding specification - and I think now with shells and constraints, also a file naming specification for DTD modules. A "design pattern" would be at a higher level of abstraction, and would merely suggest - rather than give a rule for - the best way to go about a designing a particular XML application. Otherwise it's not a design pattern - it's a design straightjacket. Here's how "Head First Design Patterns," for example, makes the distinction: Q: Is it okay to slightly alter a pattern's structure to fit my design? Or am I going to have to go by the strict definition? A: Of course you can alter it. Like design principles, patterns are not meant to be laws or rules: they are guidelines that you can alter to fit your needs. As you've seen, a lot of real-world examples don't fit the classic pattern designs. As such, I don't think a true "design pattern" could even be the object of a "MAY" conformance clause - it's too nebulous for that, until it is applied to solve a particular problem. --Dana -----Original Message----- From: Ogden, Jeff [mailto:jogden@ptc.com] Sent: Tuesday, July 07, 2009 6:54 AM To: Michael Priestley Cc: Dana Spradley; dita; Eliot Kimber Subject: RE: [dita] Conformance and interoperability You are right, there is more there than I remembered. -Jeff -----Original Message----- From: Michael Priestley [mailto:mpriestl@ca.ibm.com] Sent: Tue 7/7/2009 9:39 AM To: Ogden, Jeff Cc: Dana Spradley; dita; Eliot Kimber Subject: RE: [dita] Conformance and interoperability Hi Jeff, >My problem with "must" for the design patterns, is that the spec doesn't >seem to be specific enough about the details of the design patterns >to make them such a strong requirement. I thought the design patterns were very specific: http://docs.oasis-open.org/dita/v1.1/OS/archspec/dtdmod.html Michael Priestley, Senior Technical Staff Member (STSM) Lead IBM DITA Architect mpriestl@ca.ibm.com http://dita.xml.org/blog/25 "Ogden, Jeff" <jogden@ptc.com> 07/07/2009 09:14 AM To "Eliot Kimber" <ekimber@reallysi.com>, Michael Priestley/Toronto/IBM@IBMCA, "Dana Spradley" <dana.spradley@oracle.com> cc "dita" <dita@lists.oasis-open.org> Subject RE: [dita] Conformance and interoperability I'm more comfortable with "should" rather than "must" here. My problem with "must" for the design patterns, is that the spec doesn't seem to be specific enough about the details of the design patterns to make them such a strong requirement. Has this changed in the DITA 1.2 drafts? And while "should" isn't a strong as "must" it is still pretty strong and much stronger than other options such as "may". -Jeff -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Tue 7/7/2009 7:31 AM To: Michael Priestley; Dana Spradley Cc: dita Subject: Re: [dita] Conformance and interoperability On 7/6/09 6:26 PM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote: > I'm not sure about the should vs must being a typo. I think it's currently > must, and on purpose. Doh! You're right--I was confusing the requirement to have documents with DTDs or schemas (should) with the design pattern (must). My apologies for any confusion. Too many hours spent reviewing/writing too many pages of this spec. Cheers, E. ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]