Re: XHTML 2 / XHTML M12N 2 Publication Strategy

Greetings Shane, in order to decide on the strategy we need to be clear on 
who the intended audience is for the documents and what tasks they are 
undertaking while using the materials.

Audience could be anyone but the "intended audience" is what we need to 
identify, they may include: designers of other languages that wish to use 
modules; authors of a particular language; implementers of particular 
languages; . . . ?

An the tasks they are undertaking . . . ?

Regards, Roland



From:
Shane McCarron <shane@aptest.com>
To:
XHTML WG <public-xhtml2@w3.org>
Date:
23/01/2009 14:44
Subject:
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










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU