Re: Modules, Modularization, and the XHTML Family

(note: although experts agree that it is an "early warning sign" 
when one begins adding prefaces to one's emessages, i wanted to 
state up-front that the bulk of this emessage is simply me thinking 
aloud in response to your post, the thrust of which i support, but 
which i approach with a particular perspective -- that of someone who 
experiences the web as a purely temporal, mostly linear, expression 
of content without the ability to achieve a gestalt view of the 
document and/or application or widget with which i am interacting...  
thus the following is based on my experience and the experience of 
others whom i have worked with or assisted, and is offered solely in 
the spirit of inquiry and explanation...)

aloha, shane!

no opposition here to making our host language conformance rules more
flexible, as that will lead to more widespread implementation, or so
logic would seem to dictate...

shane wrote, quote:
>Obviously this can't be a blanket change. The rule of thumb in 
>identifying things that a host language could omit / reduce should be 
>"will a document that conforms to this language work correctly in an 
>xhtml family user agent?  And will it work in legacy user agents when 
>relying upon their interpretation of XHTML as HTML?"  Omitting the "em" 
>element, for example, would work fine.  Lots of documents don't have 
>"em" elements.  
unquote

on the other hand, a hell of a lot do -- what is needed for backwards
compatibility is a mapping between the old and the new -- mapping EM
to I would be a solution, but how good a solution is it and what 
problem is it actually solving?  i use EM in conjunction with :before
and :after CSS-generated text to provide em-quotes (what some would 
express verbally with air quotes -- as when quotes are used for 
emphatic or ironic intent, thereby providing a semantically and 
stylistically sensible means of demarcating a false quote in a manner
that can be expressed stroke rendered successfully and accurately in 
many (often overlapping) modalities...  so should the mapping be EM 
to I, or I to EM?

EM marks an "issue"; STRONG marks a "big-issue" (classes borrowed 
from standard W3C stylesheets), I means what?  B is superior to 
STRONG, why?

i know that I and B are far more common than EM and STRONG, but i 
also know what EM and STRONG mean -- moreover, in braille, there is 
no bolding, italicizing, or even effective means of underlining, so 
B and I have no meaning in those modalities (refreshable and 
embossable braille, which are 2 different media-types), while STRONG 
and EM do, or, rather, can, and are more intuitive labels to someone
who doesn't know what bold or italics look like or the impact that 
they can have on a document and its perception by the user...

shane also wrote:
> Omitting the "tr" element from the table module, on the other hand, 
> would be a disaster!

not if one is of the opinion that i am, that TABLE should be deprecated 
from markup languages, as it is a purely presentational means of 
displaying relationships through the brain's ability to perceive 
disparate items and associate each item with the headers (real or 
presentational) that mark its X/Y axis and each item's relationship to 
each other item in the TABLE, which becomes a three dimensional problem 
with heavily nested tables...

just some off the cuff remarks which somehow didn't make it out of my
mail client the day i received shane's original post...

gregory.
-----------------------------------------------------------------
Accessibility, Internationalization, and Interoperability are not
"features", "overlays" or "add-ons".  Rather, they are core 
components of any architecture -- programmatic or otherwise.
-----------------------------------------------------------------
     Gregory J. Rosmaita, gregory@linux-foundation.org
Vice-Chair, WebMaster & Listmaster, Open Accessibility Workgroup
http://a11y.org/                                http://a11y/specs
-----------------------------------------------------------------

---------- Original Message -----------
From: Shane McCarron <shane@aptest.com>
To: XHTML WG <public-xhtml2@w3.org>
Sent: Fri, 06 Feb 2009 12:20:41 -0600
Subject: Modules, Modularization, and the XHTML Family

> (I just had a call with Markus where we went over some 
> deliverables related to module implementations.  During that 
> call, we got onto the topic of host language conformance 
> requirements.  In particular, we wandered into the topic of 
> subsetting of modules.  I want to give Markus full credit here - 
> he really helped focus my thinking.)
> 
> Many of you will remember that I am fierce opponent of 
> subsetting.  The conformance rules related to module integrity 
> are largely the result of my lobbying back in the day.  So it 
> may come as a bit of a shock when I say that I have changed my mind.
> 
> The primary argument for modules, and the composition of modules 
> into markup languages, is that the structure of the resulting 
> "host" languages will be similar enough that they can be a 
> member of the XHTML Family.  Languages that are part of the 
> XHTML Family are in theory portable among XHTML conforming user 
> agents.  We get to use terms like "graceful degradation" and we 
> sound all cool and stuff.
> 
> In retrospect, I think I "grabbed the wrong end of the stick". 
>  The key to portability of content is NOT that the host language 
> support everything in a module.  The key is that the USER AGENTS 
> support the core functionality of the module so that languages 
> that rely upon that functionality will have the portability we desire.
> 
> "So what?" I hear you saying.  Well, I was thinking that it 
> would be possible to broaden the utility and appeal of our 
> modules by loosening our rules for how the modules can be used.  
> Specifically, identifying the places where it is permissible for 
> host languages to further restrict the content model, eliminate 
> elements, or eliminate attributes from attributes - while at the 
> same time making it clear that user agents are *required* to 
> support the entire module.
> 
> Obviously this can't be a blanket change.  The rule of thumb in 
> identifying things that a host language could omit / reduce 
> should be "will a document that conforms to this language work 
> correctly in an xhtml family user agent?  And will it work in 
> legacy user agents when relying upon their interpretation of 
> XHTML as HTML?"  Omitting the "em" element, for example, would 
> work fine.  Lots of documents don't have "em" elements.  
> Omitting the "tr" element from the table module, on the other 
> hand, would be a disaster!
> 
> If we were to identify the things that can be safely "subsetted" 
> in our modules, what would be the upside?  Some obvious items:
> 
> 1.  More flexibility in the application of our modules.
> 
> 2.  Greater appeal to the "structured" markup community.  The 
> folks who     brought us SGML in the first place because they 
> wanted very tight     document construction rules.
> 
> 3.  Less need to create lots of little modules since a language designer
>      can just ignore the bits they don't like.
> 
> What are the risks?  Well, first there is the significant risk 
> we will get it wrong.  Identifying candidate elements and 
> attributes is going to be painstaking.  Then there is the 
> collateral risk that user agent implementors will ignore our 
> requirements and start implementing subsets that support only 
> the host languages they care about.  Finally, there is the less 
> obvious risk that this will jump-start a plethora of xhtml 
> family host languages with their own "minted" document types 
> that existing user agents will misinterpret.
> 
> What do people think?  Am I missing something?  Would anyone 
> oppose an effort to make our host language conformance rules 
> more flexible?
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-
> 8160 x120 Managing Director                            Fax: +1 
> 763 786-8180 ApTest Minnesota                            Inet:
shane@aptest.com
------- End of Original Message -------

Received on Wednesday, 11 February 2009 14:14:12 UTC