[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Conformance and interoperability
Whew! That's a relief Eliot. Then I guess if we can just revise the few passages that seem to contradict this to make it clearer to which conformance target they apply - and change the "design patterns" phraseology to something that isn't so self-contradictory - maybe we're closer to agreement on this than I thought. --Dana -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Tuesday, July 07, 2009 11:10 AM To: Dana Spradley; dita Subject: Re: [dita] Conformance and interoperability Note that the spec as currently drafted does make the document vs. vocabulary module distinction in that it does explicitly say that conforming DITA documents need not be directly governed by a conforming DITA schema (or in fact any schema). They need only conform to the markup requirements as defined by the spec--that is, the elements need to have class= attributes and so on. This explicitly allows for DTD-less/schema-less documents that are nevertheless conforming. So making that distinction clear in a conformance spec seems both appropriate and necessary. Cheers, E. On 7/7/09 11:52 AM, "Dana Spradley" <dana.spradley@oracle.com> wrote: > 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 > > > --------------------------------------------------------------------- > 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 > ---- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]