Accessibility solutions within Joomla!

[absalom]

And who would an accessibility expert be?  According to a lot of articles all over the web, even the so called experts can't agree on what is "right" and what is "wrong".

Again, this is solved through extensibility. Anybody can 'offer' the service to do the semantics needed in this respect (so I do recognise there will be novel marketing practices irrespective of where the CMS market goes), but it's an entirely different ballgame to meet those standards properly.

By providing it in an extensible fashion, it also makes it public knowledge (or thereabouts) as to the quality of the work provided. So Andrew still gets his 'cottage industry', it's just that industry will be driven by quality, not by marketing. This will then cull the 'wannabes' out from the real accessibility experts as the trend has unfortunately been for design agencies to claim accessibility for their work when it's not. Which then leaves J! with quality code to work from in terms of semantics, instead of following their mates / 'who they like' / status quo.

[Jenny]

And who would an accessibility expert be?  According to a lot of articles all over the web, even the so called experts can't agree on what is "right" and what is "wrong".

Again, this is solved through extensibility. Anybody can 'offer' the service to do the semantics needed in this respect (so I do recognise there will be novel marketing practices irrespective of where the CMS market goes), but it's an entirely different ballgame to meet those standards properly.

By providing it in an extensible fashion, it also makes it public knowledge (or thereabouts) as to the quality of the work provided. So Andrew still gets his 'cottage industry', it's just that industry will be driven by quality, not by marketing. This will then cull the 'wannabes' out from the real accessibility experts as the trend has unfortunately been for design agencies to claim accessibility for their work when it's not. Which then leaves J! with quality code to work from in terms of semantics, instead of following their mates / 'who they like' / status quo.

What does that reply have to do with what I asked?  I didn't ask about marketing.  I didn't ask about extensibility.  I asked who would that expert be?  There are conflicting opinions from many many experts in the field as to what is "right" and what is "wrong" in terms of standards and accessibility.  What or who's idea of what or who's standards are we going to rely on as being the "right" way?  I am talking about standards, not marketing - I have no idea why you even brought that up except to go off topic.  Let's define what we're talking about then perhaps we can get to a solution instead of broad sweeping posts that ramble on about concepts, models that evaporate into  nothingness and more rambling off topic posts.

Who's idea of what defines standards and accessibility should it all be based upon?

[absalom]

What does that reply have to do with what I asked?  I didn't ask about marketing.  I didn't ask about extensibility. 

Everything, actually. Listen to what I'm saying.. Calm down, please..

I asked who would that expert be?  There are conflicting opinions from many many experts in the field as to what is "right" and what is "wrong" in terms of standards and accessibility. 

All of them. Merely because there is conflicting opinion doesn't really mean much, when they hopefully will all have the same freedom to demonstrate why their way of thinking is right in managing the semantic layer in a very public fashion. There is conflicting opinion across the D&A group as to how the semantic model should go, and there has been such conflict for a while. So the obvious solution is to learn from it and come up with an architecture that levels the playing field.

What or who's idea of what or who's standards are we going to rely on as being the "right" way? 

All of them. It will turn into a survival of the fittest codebase in terms of a semantic web. Let the accessibility experts and standards bodies fight it out on this one, MMM. You don't have to.. 

I am talking about standards, not marketing - I have no idea why you even brought that up except to go off topic. 

And I am talking about how certain firms (or players) market themselves as delivering standards-based, accessible solutions, yet fail to live up to that claim. What I am suggesting will put them front and centre into the same survival of the fittest game, at which point, they either adapt or die. That then increases the quality of the code that gets delivered to J!.

Who's idea of what defines standards and accessibility should it all be based upon?

Didn't you read that I am talking about a way of delivering accessibility across the CMS, not about following a particular standard of accessibility ?

Again: In no way am I recommending the core develop accessibility itself, just the means for accessibility and a truly semantic web to be leveraged.

[Jenny]

From that answer all I can surmise is that means you only have concepts, and models, ideas and rants. 

After the many many years you have been involved with the project.. all you have to offer is unknown promises of concepts and models, but absolutely not one bit of real life code that can actually be put to use.  I think that pretty much sums this up then. 

[absalom]

From that answer all I can surmise is that means you only have concepts, and models, ideas and rants. 

I actually have more than that, but why should I share it with you when you're being arrogant and resorting to public ad hominem slams in order to justify your behaviour ?

After the many many years you have been involved with the project.. all you have to offer is unknown promises of concepts and models, but absolutely not one bit of real life code that can actually be put to use.  I think that pretty much sums this up then. 

Merely because I don't share it now doesn't mean I won't share it soon. All good things take time.

See, what I'm suggesting actually solves the problem of accessibility for you, without you needing to think about it. It takes the best of the accessibility expertise out there and combines it with something that can be used in a CMS so those who use that CMS can benefit. And for that you attack me?

[Jenny]

Haven't attacked you once.  All I have asked is for you to back up what you say with actual real life substance.  You can't, or you choose not to, and the reality is it makes no difference which it is as the outcome is the same. NOTHING. 

Good luck with your solution. 

[absalom]

Haven't attacked you once.  All I have asked is for you to back up what you say with actual real life substance. 

Really ? From where I stand, you are attempting to publically goad meinto a flamewar, considering the terse nature and offensive tones within your posts.  I'm not going to play your game, MMM. I'd prefer someone like Jean-Marie, who remains one of the best, most impartial moderators I know, to simply cut and cull from your words on (including this very post).

You can't, or you choose not to, and the reality is it makes no difference which it is as the outcome is the same. NOTHING. 

The reality makes a world of difference because it shows the wider web world how the moderation and core team deal with those who remain different than them. And that says more about you than it does about me.

See, I've given my reasons. I've explained myself. Yet the best you can do is try and goad me. It's not going to happen.

[Jenny]

Good luck with your solutions Lawrence. Really I hope it works for you. 

[Asphyx]

And who would an accessibility expert be?  According to a lot of articles all over the web, even the so called experts can't agree on what is "right" and what is "wrong".

EXACTLY my point MMM! That is the main issue! No matter what accessability you throw in there someone who considers themself an expert can say you are not fully accessible...they can always find some non dotted I or Crossed T as an excuse to say your not compliant! And there is nothing in the LETTER of the standards that sets just how far you have to go to actually meet the spirit of the standards!

IE:
The standard says you must have a desc tag to explain images to those who can't see them... This means you can technically VALIDATE by entering a desc tag of "picture"...Technically it is valid and accessible but in reality it is not! Most who support WCAG would agree on that point! They would say you didn't describe the picture enough to make it truly accessible.

IE #2 You go a little further.
In the desc tag you say " picture of New York City". A much better and more descriptive text than simply picture but some self proclaimed expert can EASILY say well your not compliant because you have a picture of the empire state building and traffic and didn't put all that in the desc tag....

No developer can ever win while trying to comply with the standards as written! Cause even if they make a good effort and pass every validation both in robot and human terms there will at some point be some EXPERT who claims you pass the standard and fail accessability!

Again, this is solved through extensibility.

In one respect I agree on the solution...where we differ is in the need for J! to develop a WCAG extensability system wide enough for those who want to make compliant code to whatever subjective standard they desire....
The solution of extensability is EASY to implement provided something like a templated output system is in place! Such as the once proposed PatTemps scheduled for J! 2.0. But to simply add WCAG 2.0 extensability and try to encompass the 1000s of interpretations on what is needed it the hard part. I would even say impossible! (you know you can't please all the people all the time!)

Extensability does not mean locking down the product in terms of WCAG 2.0. It means opening up the output to be extensible enough to not only work with WCAG 2.0 but with 3.0, 4.0, 5.0 and 16.0 whenever they finally come out! And any other future standard that might be created!

That is what the core should be concerned with. How can we do output without having to force a particular standard or interpretation of a standard on every user...How can output be done that will allow the user to interpret and implement whatever chosen standard and level of it on their site?

That doesn't mean writing a WCAG 2.0 output system that means writing a customizable output routine!
If you want WCAG 2.0 you will be able to implement one easily! That is the only extensability that is needed!
That is the goal! Not to create some WCAG engine that will fit every interpretation via extensabiliity but to create an extensive output engine that will work for ANY standard and any interpretation of that standard!

And to do that well you can't just shoehorn that into a beta at the last minute. It takes a lot of thought and planning so that it can deal with any emerging technologies and standards as well as allow developers to go way beyond just the concept of standard and have complete control over the way output is done not only for WCAG but XML and RSS as well! If a technology came out tomorrow that was not part of WCAG that allowed complete accessibility but required say something like XML (call it AXL) would the output engine be extensible enough to support it?

You see you want extensability limited to WCAG tags not implemented in the entire output engine itself! You want to lock people into WCAG 2.0 only! And the Devs want to do it in a much broader sense and allow any standard past present and future to be allowed!

Therein lies the problem you have with what is being done here!

No, Asp, the standard isn't ambigious, however it is dependent on human behaviour and interaction.

Which means depending on which human is behaving or interacting the standard changes from one moment to the next!
I agree extensability can solve this ambiguity. But the solution should solve the ambiguity for those who don't agree that WCAG 2.0 is the only way to solve these problems! If a new standard came out tomorrow I sure don't want to be locked into 2.0 no more than you would want to be locked into WCAG 1.0 now that 2.0 is out!

Extensability as I said is the goal! EVERYONE AGREES on that point! The only difference is you want this extensability to only encompass WCAG 2.0 whereas the Devs (and I agree) want extensability PERIOD! Then the user can decide if they want WCAG 2.0 or 1.0 and any other flavor of output they choose because they can customize the output to any standard they interpret as VALID!

You'd be wrong on that. I recognise I'm part of a minority in the web industry, but I'm clued in and willing and able to educate anyone as to what is needed to get their sites / CMS / products in order.

I know your passionate and charitable in sharing what you know about Accessability and I don't think anyone can fault you for that on any score...And I respect your knowledge of Accessability interms of WCAG. But lets for arguments sake say you helped me make what you define as truly accessible...there will always be some OTHER "EXPERT" who can come by and claim my site isn't valid because his interpretation of what is valid is different than yours!

I agree with you wholeheartedly that the ABILITY to meet WCAG 2.0 criteria in the CMS via extensability is something that Joomla needs...Where I think we differ greatly is I want the extensability to be open enough so that WCAG 2.0 isn't the only thing extended!
It's not enough to just add columns and fields for every tag that WCAG2.0 requires...

What is needed more is an output system that will be WCAG 3.0 and 4.0 capable as well!
And the only way to do that is to create a system that does not CARE what standard the user tries to implement. It's only goal is to make a system that can support ANY standard that may come out now or in the future!

Closing the system to WCAG 2.0 only means we have to go through all of this again when 3.0 comes out!
Extensability is good. but it needs to extend the entire system in more than just WCAG 2.0 terms!

And that isn't something you can just throw into 1.5! That is why it is scheduled for 2.0 so it can be done right!

[absalom]

Extensability as I said is the goal! EVERYONE AGREES on that point! The only difference is you want this extensability to only encompass WCAG 2.0 whereas the Devs (and I agree) want extensability PERIOD! Then the user can decide if they want WCAG 2.0 or 1.0 and any other flavor of output they choose because they can customize the output to any standard they interpret as VALID!

What the ? I in no way have ever voiced the view that extensible WCAG 2.0 is the way to go. I have always voiced the view that an extensible, ubitiqious, device agnostic solution is needed, considering I've been discussing how to solve this problem for at least a year. The project manager can then decide if they need WCAG 2.0 or 1.0 and any other flavour of output they choose because they can customize the output to any standard they need to deliver on, by getting credible accessibility experts to develop and deliver (and maybe share globally) that semantic model.

Seems to me wires of communication may be crossed prior or during my forced absence...

[Asphyx]

Well I'm going on past conversations (some we had on other sites) in regards to MVCR output.
If I misubderstood then (possible...) then please accept my apology!

In those conversations you were upset that all output wasn't forced through a WCAG 2.0 output layer incuded in the core.
At the time you wanted J! Devs to make a WCAG2.0 output layer (using PatTemps or some other system) that all 3PDs would be forced to use.
Your main concern was that the 3PDs were not being forced to use Joomla standard output and that they were themselves creating the output section of their project to be added to the J! output system.

I believe your concern then was (rightful concern I might add) is that the 3PD if given the keys to creating their own output would allow the inexperienced 3PDs to make non WCAG compliant code.

but No matter which way you lean on that score, the task to add that extensability and flexability into a complex system like Joomla is a very large nut to crack!
Think of the work involved. It is much more than just rewriting the output layer and making it extensible. an entire output configuration system must be built so that you can assign different content items  (and extentions) to the customized extensible layer! IT's not about just extending how you output, it also must extend the backend so you can edit, configure, assign content to a particular output routine and then save all that info in the database!
On top of all that it should also have a system that will allow users to download and install entire output stylings for use in their site. Me and you can probably rewrite the routines for accessability, But many users of J! are not proficient in PHP and accessability and can not easily use a system like this unless it is made particularly user friendly!
What we both want is in essence an entire framework unto itself built to focus on output and extensability of output.

It can not just be ADDED to 1.5 since in all likelyhood it will totally break many extentions and sites who simply want to upgrade to the new framework. J! 1.5 is a transitional release. It's not really a ADD FEATURES release (although some new features are present.) It is being made to remove past limitations of the legacy code so that all of these features we want can be built in.

I actually support this one LACK of feature on this principle....
The Devs made a thoughtful decision and decided, if we can't take our time and do this system right for release in 1.5 then lets spend all of our time on the main J! 1.5 framework building it with these sorts of future features in mind. they concentrated in the foundational infrastructure needed to complete such a complex task like output extensability for J1.5 and worked instead on making a system that would bring leagacy users along to the new system with the least amount of hardship.

It is more important (IMO) to make a transition from the old framework to the new much easier and simple for the many users who are currently running J! than it is to try and entice more NEW USERS simply because it now does full WCAG output because of an extensible output layer!

Cause the bottom line here is if the transition to the new framework is a major pain in the ass and breaks many a site well no one will make that transition. And that means a fractured userbase and much confusion for 3PDs on which framework to develop for!

The Devs IMO took the prudent and thoughtful path with 1.5!
Customized output is important but it can wait until 2.0. It's not as important as making the transition to the new framework as easy and as backwards compatible as it can be.
Because if no one upgrades to the new framework then there won't be a Joomla 2.0 just a joomla 1.0.20!
No one will use the newer more advanced framework that will allow all these things we both want done!

[absalom]

Well I'm going on past conversations (some we had on other sites) in regards to MVCR output.
If I misubderstood then (possible...) then please accept my apology!

In those conversations you were upset that all output wasn't forced through a WCAG 2.0 output layer incuded in the core.
At the time you wanted J! Devs to make a WCAG2.0 output layer (using PatTemps or some other system) that all 3PDs would be forced to use.
Your main concern was that the 3PDs were not being forced to use Joomla standard output and that they were themselves creating the output section of their project to be added to the J! output system.

OK. You've seriously misunderstood. If you've misunderstood, that probably means the Core has misunderstood as well, and they've banned people for their own misunderstanding over this.

My main concern has been (for the last year or so) that there isn't a ubiquitous semantic structure between / through components, modules and plugins. This is due to the Core saying semantic and data structures remain CMP-locked and following that mentality to the letter. You can't share data between bits of the CMS. You can't remix or mashup componentry on the fly. You likewise have to reinvent the wheel by replicating the same code over and over again. And then there's the whole semantic issue.

All components (com_content, com_weblinks, com_ whatever) should have the ability to have the same heading / content structures styled in the same way, by using a WORM solution that creates the semantic model for them and they then all gain the same benefits. It is, after all, a content management system, and really all components do is output differing forms of data into some content structure (this applies to CMS design in general as well). This philosophy again appears foreign to the Core mentality because they want to pass the buck for accessibility and semantic well-formedness (i.e output) for their work to 3PDs through stuff like the override hack.

In no way does this imply 3PDs would be forced to follow the Core coding through a semantic library, but simply means 3PDs, if they choose to, can gain the same semantic benefits that could be envisioned for core code, if they followed the same templating schema. It's based on an ease of use buy-in. By making it easier for core and 3PD work to both be accessible, extensible and semantically well formed at the same time, it means people can then think more about the quality and direction of their work as the problem would be solved "silently" for them.

I believe your concern then was (rightful concern I might add) is that the 3PD if given the keys to creating their own output would allow the inexperienced 3PDs to make non WCAG compliant code.

They do already. In no way would this stop as people can and do construct bad CMPs that interface to the CMS.

All I would really be doing is providing an alternative path for them to leverage the same templating schema that would have been "core" so that they gain the same semantic benefits / accessibility structures as the "core". In this way, core and 3PD work then start being a unified strategy, instead of the Core treating 3PD work like it was some black sheep or child born out of wedlock. See, at the end of the day, both core and 3PD work need to follow the same structures and guidelines to get the same benefits, and the really simple way of delivering it to both of them is via a templating schema.

but No matter which way you lean on that score, the task to add that extensability and flexability into a complex system like Joomla is a very large nut to crack!

Let's just say we're a lot closer to cracking that nut that we were 3 years ago, when this problem was first identified.

Think of the work involved. It is much more than just rewriting the output layer and making it extensible. an entire output configuration system must be built so that you can assign different content items  (and extentions) to the customized extensible layer! IT's not about just extending how you output, it also must extend the backend so you can edit, configure, assign content to a particular output routine and then save all that info in the database!

You're approaching this from the wrong direction, at least from where I stand. You don't rewrite the output layer (at the end of the process). You fundamentally rethink the way CMPs are designed from the ground up - which is why I became more vocal the closer we got to feature lock-in of 1.5 Beta. See, with 1.5, we had the opportunity to rewrite CMP structures to be device agnostic (
remixing or mashups). That didn't happen. We likewise had an opportunity to make the semantic layer across all core CMPs to based on a templating schema. That didn't happen either. CMPs have been rewritten for 1.5, yes, but not to the extent that was needed to give these benefits to the wider community.

That means, at least from what I can ascertain from Core "policy" and discussion, that these sorts of things are 24 to 36 months away now with J! 2.0, even though the ideas have been floating around J! since it's inception (thanks to Vav and others).

On top of all that it should also have a system that will allow users to download and install entire output stylings for use in their site. Me and you can probably rewrite the routines for accessability, But many users of J! are not proficient in PHP and accessability and can not easily use a system like this unless it is made particularly user friendly!

I've thought through this and I have some ideas on how to solve it, thanks in part to my discussions with Jeffrey Veen a few years ago.

What we both want is in essence an entire framework unto itself built to focus on output and extensability of output.

Correct. In no way does that mean it has to be WCAG 2.0. I forsee there would be a time when your site admin negotiates with a reputable accessibility consultant as to what your site needs (WCAG, ATAG, 508, etc..) and to deliver that semantic model, all they do is implement something according to a predefined template schema.

It can not just be ADDED to 1.5 since in all likelyhood it will totally break many extentions and sites who simply want to upgrade to the new framework. J! 1.5 is a transitional release. It's not really a ADD FEATURES release (although some new features are present.) It is being made to remove past limitations of the legacy code so that all of these features we want can be built in.

My point was.. if you're going to do a decent point release, you may as well do it now. This was the philosophy that existed in the U&A team when Vav was guiding it (with the potential 1.1 and 1.2 roadmaps for accessibility). Since the window has now closed, we are looking 2 to 3 (maybe even 4) years from now before anything even gets recognised as valuable in terms of J! core principles. What makes it even worse is that the core has said post-1.5 the roadmap is undefined.

The Devs made a thoughtful decision and decided, if we can't take our time and do this system right for release in 1.5 then lets spend all of our time on the main J! 1.5 framework building it with these sorts of future features in mind. they concentrated in the foundational infrastructure needed to complete such a complex task like output extensability for J1.5 and worked instead on making a system that would bring leagacy users along to the new system with the least amount of hardship.

The problem, from where I stand, is that it hasn't been built with these sort of future features in mind, since we're still at CMP-dependency, even with the template overrides.

Will it take another 3 years before CMP dependency gets phased out ?

Customized output is important but it can wait until 2.0. It's not as important as making the transition to the new framework as easy and as backwards compatible as it can be.
Because if no one upgrades to the new framework then there won't be a Joomla 2.0 just a joomla 1.0.20!
No one will use the newer more advanced framework that will allow all these things we both want done!

Ah, you're still not thinking about the buy-in principles. If it's easier for a developer to code to some templating schema that does the heavy lifting for them than to hand craft, duplicate and replicate an existing structure of a CMP (in the current form), which path do you think they'd choose ?

1.5 was already "advanced", anyway. So what's stopping it from becoming more advanced now ? Two things, from where I stand:

• Beta equals feature lock down
• Core development is not committed in any way to device agnosticism of any form (CMP / semantics / whatever)

[Asphyx]

You're approaching this from the wrong direction, at least from where I stand. You don't rewrite the output layer (at the end of the process). You fundamentally rethink the way CMPs are designed from the ground up

This is where you miss the point on 1.5 entirely! Your asking for a new feature. That is NOT the purpose of J! 1.5!

Rewritten and redesigned from the ground up will break every component and extention that exists today! (or damn near every one....)

the purpose of J1.5 is not to redesign the subroutines used for different functions but to redesign the framework to modularize those functions. That is the entire purpose!
It is meant to organize the subroutines currently being used and modularize them so that later on each subroutine can be rebuilt or redesigned much more independently than current!

You never seem to understand that part which is why you don't like the answers the Devs have given you whenever this is brought up!

J! 1.5 is basically a modularized version of the same codes used by J1 1.0.X. Only now those codes are compartmentalized and seperate so that the framework doesn't need to be redesigned each time you want to update a subsystem.
This modularization goes far beyond just the limited scope of output. It also encompasses ACL, DB support and any other subfunction of the system you can name!

J! 1.5 is a reorganization task that is meant to bridge the gap between 1.0.X and the new modular framework. To add an entirely new subsystem would lead to the problems J! 1.5 is meant to solve!
And that is to make as painless as possible the transition from the old to the new so that the new will allow the Devs to add all these functions and more to the system in an easy and modularized way!

The main purpose of redoing the framework was to seperate not just logic from output but to seperate logic sub routines from other subroutines according to function! Now not only is the Output extensible but so is the calls to the DB, and the Calls to ACL.
Before you can make an extensible output module there has to BE an output module to work on.
this was not the case under the old framework. J! 1.5 corrects that. And now that there is a module to work on, the work you want can be done for J! 2.0

Currently the extensability with the new framework allows what you want. but the module for output is still very much like legacy 1.0.X code. IT was done that way for compatability. think of it like an extra port on a computer you aren't using right now but will in a few weeks when you have the equipment to plug into it! J! 1.5 supplies the port not the equipment yet. That isn't scheduled until J! 2.0

All components (com_content, com_weblinks, com_ whatever) should have the ability to have the same heading / content structures styled in the same way, by using a WORM solution that creates the semantic model for them and they then all gain the same benefits.

But that is not enough Ab....
because that does not give the end user an easy way to set and turn the worm! And that is more important than this buy in! What of a user who wants to have a different heading and structure based on section or content item? How do they define that in the backend? Cause that is the real trick here!

It is quite easy to make a sort of CSS type system of PHP where different subroutines of code act as output tags for different content items. That is not the hard part. It is making the backend able to configure which content uses which set of functions and designing that CSS of PHP templating system to accept the many different flavors of code that allow that concept. thoise are actually two seperate modules (or should be) under the working model of the new framework.

Here is the goal of the Devs I think you really aren't getting or understanding....
the Devs have repeatedly stated they do not want to LIMIT users in their output rendering system they want to allow more choice so that someone who does not want to deal with the complexity of PatTemps can instead install a Shorty module in it's place! this kind of extensability goes far beyond your expectations of what is extensible as it allows any new and emerging output rendering systems to be used and simply installed! In future you might even be able to mix and match if done correctly! (although I can't see why you would want or need that)

Under this approach you are not only offerring 3PDs the chance to buy into what exists you are allowing the user to choose what exists in the first place! This is the right way to go and to do it it can not be something just thrown in!

It has to be well thought out and the logic in the backend that controls it must also be flexible to be able to control whatever system the end user decided to use for output rendering!

That means creation of output routines, Assignment of said routines to each content item and component and the ability to cusomize individual content items when desired.

That is much more complex than you are proposing which is probably why you don't know why they have put it off untill later!

They are going an extra mile and taking an extra release full version number to do it so that it is done right!

Sure they could put the piece meal solution you want!
But it would make backward compatability problematic and it would be wasted work once the Devs started on the fully and more extensible solution they have planned is done!

[Jinx]

Hi guys,

I'll give this one, one last shot.

First of all, the philosophy of the U&A team has been from the beginning to introduce modern webstandards and accessibility standards in Joomla!. At first the goal was to remove tables and target WCAG 1.0 or 508. Later this moved to WCAG 2.0. I have never seen nor read any discussions inside the U&A team about the concepts that Absalom is describing.

I also see a difference in the concepts he is advocating today and the concepts he was advocating on the forums a few months ago. I can understand his ideas have shaped up while he studied the matter but until today the only thing he showed us are ideas and rants. So far he hasn't been able to create any decent proof of concept to demonstrate the theories he is talking about.

Presenting a proof of concept would only be a first step towards a possible solution. However implementing any of those concepts would be out of scope for 1.5. We have tried to explain this is numerous posts time and time again. I'll give it a last try.

The semantic structures created by extensions remain indeed locked into the extensions context. This is not something new, nor would it be fair to blame the core team for this. This concept has been part of the Mambo architecture from it's very early versions. The Joomla! and also Mambo architecture is built in a vertical way not in an horizontal way. Extensions can use the framework API's but can't talk to each other.

The Joomla! architecture threats an extensions as a black-box. It doesn't care about what the extension does or how it does it's magic. The only thing the framework does is execute the extensions if needed and acts on the information the extension returns. For Joomla! 1.5 extra care was taken to further decouple any existing coupling between core extensions to further strenghten this principle.

Changing this very basic concept of the Joomla! architecture would be mean throwing everything up side down and if I corrcetly understand Absalom his ideas this would be needed to make a 'semantic template schema' possible. It would mean breaking full backwards compatibility and strating from scratch. We have choosen not to do this for obvious reasons. If such a major concept change would ever be made it can only be done in a major release. Before we would even start to consider it a very decent proof of concept would need to be delivered.

[Asphyx]

Ok Jinx now straighten me out so I don't risk misleading other users....LOL

From a conversation we had awhile ago you mentioned MVCR as opposed to MVC as the way Joomal was intending to handle output. The extra R (for renderer) was with the idea that an end user could select the renderer they wanted...Am I wrong on that score?


I assumed from that conversation (and we all know what assuming gets you LOL) that you were trying to devise a way that would allow users to implement PatTemps or Shorty which in turn would also be open enough to allow any other type of Rendering engine that came along...A difficult task requiring lots of thought and even more man hours to do right. Much more than could ever be done for something like 1.5

And at the time I fully understood both from that conversation and the way the roadmap put it that it was never planned for 1.5 and that 1.5 needed to be proofed and the framework tested and finalized before any extention of output functionality could be made if for no other reason than if the framework wasn't finalized how could anyone possibly start interfacing with it in such a complex and heart of the system function such as output.

Now it has been some time since we talked about that and we haven;t really touched on that subject since but for clarification, Some sort of user customizable output is planned for 2.0. How open ended as far as renderer or if the MVCR is even still the way to go won't even be discussed until 1.5 beta is final, but some system yet to be named or devised will be targeted for 2.0 that will allow some user customization of output...Am I at least correct on that score?

Even an answer of I don't know is acceptable to me I just don't want to be spewing garbage and later on having someone say well Asp said you were doing this and I was wrong!

you don't need me making any problems for you! LOL

[Jinx]

From a conversation we had awhile ago you mentioned MVCR as opposed to MVC as the way Joomal was intending to handle output. The extra R (for renderer) was with the idea that an end user could select the renderer they wanted...Am I wrong on that score?

No you are not wrong in that case, and part of this concept is already present in 1.5 through the JDocument library. The system allows for output format switching between different renderes, in 1.5 we support html (default), feed, pdf, xml and raw. This implementation isn't fully transparent to the component, a component still needs to add support for one type of renderer. In future versions we want to strive to more transparency and thus less code that needs to be written by the component developers.

I assumed from that conversation (and we all know what assuming gets you LOL) that you were trying to devise a way that would allow users to implement PatTemps or Shorty which in turn would also be open enough to allow any other type of Rendering engine that came along...A difficult task requiring lots of thought and even more man hours to do right. Much more than could ever be done for something like 1.5

There is a difference between the output format and the template engine used to create this output. patTemplate and Smarty are examples of template libraries that expose presentational logic to template designers. These libraries could be as possible engines that get's used by the renderer to create parse a template file one of the goals is to make the system template library independant. This goal was already partly met in 1.5. The current view implementation in the component MVC allows for easy implementation of an template engine.

And at the time I fully understood both from that conversation and the way the roadmap put it that it was never planned for 1.5 and that 1.5 needed to be proofed and the framework tested and finalized before any extention of output functionality could be made if for no other reason than if the framework wasn't finalized how could anyone possibly start interfacing with it in such a complex and heart of the system function such as output.

This is almost correct, as we already explained 1.5 is a transition release we can only do so much. More work on the output layer and core architecture can only happen in a next major release.

Now it has been some time since we talked about that and we haven;t really touched on that subject since but for clarification, Some sort of user customizable output is planned for 2.0. How open ended as far as renderer or if the MVCR is even still the way to go won't even be discussed until 1.5 beta is final, but some system yet to be named or devised will be targeted for 2.0 that will allow some user customization of output...Am I at least correct on that score?

Something like that, again we already met this goal partly by implementing the template overrides in 1.5.

Hopes this helps

[Asphyx]

Thanks Jinx....

That cleared up a few things I had wrong....
I was under the impression the render section was the templated part but I realize now that when you meant render you were talking about PDF, RSS, HTML etc as in what code format the view was finally built in and sent as.

So the templating would actually be done in the View stage and that view can then be constructed in many other delivery formats.

That actually sounds a lot better than what I thought it was! LOL

[absalom]

First of all, the philosophy of the U&A team has been from the beginning to introduce modern webstandards and accessibility standards in Joomla!. At first the goal was to remove tables and target WCAG 1.0 or 508. Later this moved to WCAG 2.0. I have never seen nor read any discussions inside the U&A team about the concepts that Absalom is describing.

I'd beg to differ on that, especially since Nic and I were advocating some form of templating engine since J 1.1 was first approached, back in October last year. You did read the posts in the U&A forum about potentially styling the frontend and backend of the CMS with the same approach, or did they get culled and censored like the rest of my work round here ? (As I'm missing 30 odd posts and most of them seem to be key ones I wrote on the U&A forum).

I also see a difference in the concepts he is advocating today and the concepts he was advocating on the forums a few months ago. I can understand his ideas have shaped up while he studied the matter but until today the only thing he showed us are ideas and rants. So far he hasn't been able to create any decent proof of concept to demonstrate the theories he is talking about.

The reasons I haven't shared code yet:

• Censorship and biased moderation against any discussion and against my person (so potentially libellous action on a US server) on this topic
• There are some parallels with what happened with Nic as what has happened with me over the last month - when he tried to pitch a similar idea as part of the Core team which was rejected. This means there is an existing precident that at times the Core doesn't play well with others especially when it comes to accessibility. Has the Core changed or learnt from what happened with Nic ? From what I can see, not at this time.

Presenting a proof of concept would only be a first step towards a possible solution. However implementing any of those concepts would be out of scope for 1.5. We have tried to explain this is numerous posts time and time again. I'll give it a last try.

Which is where Franck's comments about an Advanced Labs / Business Unit working group with coders and designers who can deal with this topic and the other major ones affecting large scale commercial rollouts matter. If that WG was in existence, we could then create an Advanced version of 1.5, without backward compatibility, solving all of the large scale user issues (ACL, accessibility, multilevel).

I'll give my solution publically when I feel I will not be censored / have my work bastardised without attribution, copyright or respect. Not before..

The semantic structures created by extensions remain indeed locked into the extensions context. This is not something new, nor would it be fair to blame the core team for this. This concept has been part of the Mambo architecture from it's very early versions. The Joomla! and also Mambo architecture is built in a vertical way not in an horizontal way. Extensions can use the framework API's but can't talk to each other.

But there was extensive discussion on Mambo prior to the split and the early comments here that CMP dependency needed to remain, iirc.

Changing this very basic concept of the Joomla! architecture would be mean throwing everything up side down and if I corrcetly understand Absalom his ideas this would be needed to make a 'semantic template schema' possible. It would mean breaking full backwards compatibility and strating from scratch.

So ? I'm not the only person advocating that we throw backwards compatibilty out the window in order to get this solved now. Franck and his comments throughout the Group Management / ACL thread also speak of this, plus a few other players as well.

We have choosen not to do this for obvious reasons. If such a major concept change would ever be made it can only be done in a major release. Before we would even start to consider it a very decent proof of concept would need to be delivered.

And I've explained my reasons as to why the PoC isn't public at the moment.

[Jenny]

Lawrence, either you want to contribute or you don't. You have made the conscious choice not to contribute. Your loss, our loss, everyone's loss.  Life goes on, loss is recovered from.

It really is as simple as that. 

[absalom]

Lawrence, either you want to contribute or you don't. You have made the conscious choice not to contribute. Your loss, our loss, everyone's loss.  Life goes on, loss is recovered from.

It really is as simple as that. 

I am contributing. I'm just doing it so I can be sure the work I do will be credited and treated fairly, unlike certain behaviours of other community members around here. My work and my code is still my gain, after all. I get to choose who I share that knowledge and code with..

It is good that you acknowledge there has been loss amongst J!. What I am talking about does not place me as the first, but yet another member, in a long line of people who have been made unwelcome around here. And who's fault is it that a community that is welcoming isn't created ? The core and the moderators, since these are the two main political power bases on this forum.

[brad]

I'm just doing it so I can be sure the work I do will be credited and treated fairly, unlike certain behaviors of other community members around here. My work and my code is still my gain, after all. I get to choose who I share that knowledge and code with.

Will this solution be available as an open source or commercial application?

It is good that you acknowledge there has been loss amongst J!. What I am talking about does not place me as the first, but yet another member, in a long line of people who have been made unwelcome around here. And who's fault is it that a community that is welcoming isn't created ? The core and the moderators, since these are the two main political power bases on this forum.

You are one of only a handful who feel that we (me) are unwelcoming. Without the community, Joomla would be just another open source project. However with the huge community filled with welcoming and helpful people, Joomla is now the most popular open source CMS today.
Surely you don't think that we have reached this stage with just the input of a handful of people (Core Team)? We certainly don't take the credit ourselves for the success of Joomla.

..but I'm glad I am a Core Team member, otherwise I would be insulted by your inference that everyone who is not a Core Team member cannot think for themselves and just blindly follows the Core Team without even using their own minds to form an opinion. I think far more of the many 1000's of community members who make the community so welcoming and offer so much valuable help, all for free... shame one you for trying to put so many people down!

"No one can make you feel inferior without your consent" - Eleanor Roosevelt
I refuse to accept your opinion of the community, and I suggest you give a bit more credit to the others among the community who are neither moderators nor Core Team members... 16 votes in your poll, even if they all supported you view, I'd hardly call that a majority.

There are so many other open source CMS projects around, if you feel Joomla is so deficient in code and community, why are you still here?

You know, we get ideas, suggestions and offers etc etc all the time, but things would be unable to move forward if there was nothing but talk. There comes a time when someone has to make decisions and take action to actually 'code' Joomla. It's hard, you can never please everyone, but constant harassment and talk without real concrete solutions would give us no project at all, and certainly no community. As Bill Cosby once said: "I don't know the key to success, but the key to failure is trying to please everybody."

"The hopeful man sees success where others see failure, sunshine where others see shadow and storm" - O S Marsden
You're seeing too much failure and shadow and storm. In reality the sky is bright

I'll be down in Melbourne in a few weeks, and if you promise not to talk about Joomla accessibility and the 'problems' in the community, I'd love to buy you a coffee...

[Asphyx]

Ab - Joomla is open source....

There is nothing to stop you or Fanck or Nic from adding what it is you think you have to the 1.5 Beta code and getting copyright of the work you added!

If you want a completely different Jooma 1.5 from everyone else then why don't you just make it already?

So ? I'm not the only person advocating that we throw backwards compatibilty out the window in order to get this solved now.

Sure your not the only one...there are three of you that think screw backward compatability....I'm sure I could easily take a poll here and find you are the only 3 that really want to make 1.5 totally un upgradeable from J1.0.x and all it;s current components. There would be 300 that will vote that if their current site won't run under it seamlessly they won't upgrade at all!

The Devs have said and I agree that J 1.5 is meant to be backward compatible so that most users will not stay away from it for fear of their site breaking!

everyone got a chance to say what they wanted to be in 1.5...
some people didn't get what they wanted...that is life!
More people got what they wanted than didn't!

So as I see it you have to choices. If it is that important to do this in J! 1.5 then put it in there! Don't keep complaining that someone else won't do it for you!

I would love to have the feature...But not at the expense of not being able to run my current site under 1.5! To me the backwards compatability right now is much more important to Joomla's future in regards to the 1.5 framework than anything that could potentially run under that framework in the future!

But as I said...you can make a fork to copyright your work and submit your proof of concept!
Then the users will decide if what is more important to them right now...Backwards compatability or this extensible output!

[absalom]

Will this solution be available as an open source or commercial application?

I forsee it as sharable, and therefore open sourced. I've said this elsewhere, but it seems to have fallen on deaf ears.

You are one of only a handful who feel that we (me) are unwelcoming. Without the community, Joomla would be just another open source project. However with the huge community filled with welcoming and helpful people, Joomla is now the most popular open source CMS today.
Surely you don't think that we have reached this stage with just the input of a handful of people (Core Team)? We certainly don't take the credit ourselves for the success of Joomla.

But you do hold the political and social and ethical keys of power for the entire community. As far as I can tell, that power does not include any admission of wrongdoing when certain players in this community have played on subtle libel towards me, my business and whatever I choose to bring to this community. During the time I was forcibly removed from this community, I identified 4 instances of a bias, partial, potentially libellous thread regarding my person in which nothing was done, apart from the other instances I have elsewhere.

..but I'm glad I am a Core Team member, otherwise I would be insulted by your inference that everyone who is not a Core Team member cannot think for themselves and just blindly follows the Core Team without even using their own minds to form an opinion.

The problem is now I have significant, quantifiable evidence that the moderation team engages in bias moderation to the point of allowing libellous claims on a US server. As the moderation has been biased against me (and I have proof of that action), it does not matter if people follow you. Bias is bias.. and that means certain topics cannot and will not be discussed.

I think far more of the many 1000's of community members who make the community so welcoming and offer so much valuable help, all for free... shame one you for trying to put so many people down!

I'm not putting them down by any means, Brad. Their contributions matter as well. The evidence I have concerns biased moderation to the point of libel against me.

I refuse to accept your opinion of the community, and I suggest you give a bit more credit to the others among the community who are neither moderators nor Core Team members... 16 votes in your poll, even if they all supported you view, I'd hardly call that a majority.

Not my point. Not even close to my point. Yes, the Core team deserve credit for what they've done. The problem within the community structures is that biased moderation to the point of libel has occured. The other problem is that the Working Group structures provide no recognised appeal process, so if the Core dictates a decision, that decision is final, even if that decision is wrong and/or potentially libellous on their part. These issues do need to be addressed in some manner.

These issues remain independent of accessibility or anything else. These issues affect the identity and function of the community, and not the code.

There are so many other open source CMS projects around, if you feel Joomla is so deficient in code and community, why are you still here?

Because I can help solve the problems I see. Because the people within this community matter, even if the WG and Core politics suck (which is an area you guys need to work on). Because the product is good, even if it does have significant shortcomings. And since I know the product (since I've been working with it for 3 years now), why shouldn't I help out by transferring my knowledge and skills to the people who need it ?

You know, we get ideas, suggestions and offers etc etc all the time, but things would be unable to move forward if there was nothing but talk. There comes a time when someone has to make decisions and take action to actually 'code' Joomla. It's hard, you can never please everyone, but constant harassment and talk without real concrete solutions would give us no project at all, and certainly no community. As Bill Cosby once said: "I don't know the key to success, but the key to failure is trying to please everybody."

Which is where I've always agreed with Franck's view on an Enterprise WG. It's not a new idea by any means, from what I understand of Franck's work, as something similar was suggested by him when we were first trying to set up the U&A WG with Nic (still have it in PM).

You're seeing too much failure and shadow and storm. In reality the sky is bright

I've got evidence that moderation has gone to the dogs.. Not as bright as you think, so from where I stand, it's a bit too rose-coloured glasses from where I stand. And since the political powerbase on this forums seems to be that the Core/mods don't acknowledge when they screwed up (e.g. no appeal process in Forum rules, WG, Core, anywhere) , none of the apparent social / community issues get addressed.

I'll be down in Melbourne in a few weeks, and if you promise not to talk about Joomla accessibility and the 'problems' in the community, I'd love to buy you a coffee...

I'll buy you a coffee anyway, if you're willing to hear me out.