W3C home > Mailing lists > Public > public-xhtml2@w3.org > January 2009

Re: XHTML 2 / XHTML M12N 2 Publication Strategy

From: Shane McCarron <shane@aptest.com>
Date: Tue, 27 Jan 2009 08:47:14 -0600
Message-ID: <497F1E72.6010501@aptest.com>
To: Roland Merrick <roland_merrick@uk.ibm.com>
CC: XHTML WG <public-xhtml2@w3.org>, public-xhtml2-request@w3.org

Fair point.  I think it is clear historically that the intended audience 
for M12N documents is language designers.  This should be the case for 
our free standing "modules" too - the modules like Access really only 
make sense in the context of a complete markup language.  They are 
enabling technologies, not solutions.  It is arguable whether this 
audience needs to the schema implementation(s) embedded in the 
publication or not.

MarkUp language specifications, on the other hand, probably have an 
intended (primary) audience of document authors.  I would argue that 
document authors don't care about the schema implementations at all. 
The might care about validation, but not what the schema is that 
supports that validation.

Not sure if that helps in the decision process or not.



Roland Merrick wrote:
> 
> 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/
> 
> 
> 
> 
> 
> 

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Tuesday, 27 January 2009 14:49:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:50 GMT