OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

  • 1.  RE: [dita] Conformance and interoperability

    Posted 07-07-2009 13:55 
    You are right, there is more there than I remembered.

   -Jeff


  • 2.  Regrets for today's meeting

    Posted 07-07-2009 14:51 
    I truly hate to miss today's TC meeting, but I need to take a neighbor 
to a local urgent-care clinic.

Kris


  • 3.  RE: [dita] Conformance and interoperability

    Posted 07-07-2009 16:51 
    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


  • 4.  Re: [dita] Conformance and interoperability

    Posted 07-07-2009 18:10 
    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"


  • 5.  RE: [dita] Conformance and interoperability

    Posted 07-07-2009 20:32 
    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


Related Content