XHTML 2 / XHTML M12N 2 Publication Strategy

In speaking with Mark yesterday, I realized that the strategy we have of 
  bundling our schema implementation(s) with our specifications might be 
making it harder for our readers.  The specifications are getting so 
large that they are becoming unapproachable (the M12N 2 spec is 300 
printed pages, but that includes our issues and schema).

I wonder if we should consider splitting these specifications?  Part 1 
could contain the prose and abstract module definitions, and Part 2 
could contain the implementations?  Would that make the specs less 
intimidating?  Would it make it easier for us to update the 
implementations as we find errors in the future?

On a related note, we will soon need to decide on what is in the XHTML 2 
spec vs. what is in the XHTML M12N 2 spec.  Right now I am just 
duplicating all the content they have in common, with the M12N version 
saying that the XHTML 2 version is definitive.  That's just to avoid 
confusion in the short term.  In the long term, I believe we should 
adopt the following strategy:

1.  Leave the independent modules we have defined free-standing if
     they can be (XHTML Access, Role, RDFa).  If they cannot, either
     update the independent version or migrate them into M12N 2.0.

2.  Have M12N 2.0 be the definitive collection of core modules
     and their semantics.  Include in this document not just the
     modules used in XHTML 2.0, but also any legacy modules that
     we want to bring forward (legacy forms, legacy presentation).

3.  Have XHTML 2.0 contain the complete (not minimal) content model
     definition for each of the modules it uses, but contain
     no semantics - instead deferring to M12N or the free-standing
     specifications for those definitions.

I think that this approach is most consistent with our charter and our 
goals.  Moreover, it gives our constituents the greatest flexibility in 
constructing new markup languages using XHTML Modules and modules from 
other sources (XML Events, XForms, SVG, MathML, ARIA).

On the downside, it means that the XHTML 2.0 specification is not 
internally complete - it will not contain all of the information a 
document author needs to understand what each element / attribute does. 
  However, I think we have already crossed this bridge, since many of 
the modules on which we depend come from other sources and we are not 
duplicating their content (for obvious reasons).

The other disadvantage is that we are again producing a specification 
(M12N 2.0) that is a toolkit, not a markup language.  This seems to 
confuse some people.  However, I think we have a long track record of 
producing such tools and we should continue to give our constituents the 
tools they need to do their work (e.g., Jabber, DAISY).

Opinions?
-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 23 January 2009 14:43:13 UTC