extension model (was Re: TCDL Draft F)

Hi,


Christophe Strobbe wrote:
>>> * there is now a chapter on the extensibility mechanisms;
>>
>> I quite strongly disagree with this extension model. IMO, parsers 
>> should simply ignore elements and attributes they don't know, and let 
>> the chaos have its way... ;)
> 
> I don't understand why you disagree, unless you want to allow undefined 
> elements and attributes *anywhere* in a TCDL file. This would require 
> that I add xs:any (= any elements) before/after every defined element 
> and that I add xs:anyAttribute to any element. Is that really what we 
> want??

What is wrong with *any* additional elements and attributes to pop up anywhere within the a TCDL file? As long as the required elements and attributes exist and adhere to the basic restrictions (such as cardinality restrictions etc) then a file should be deemed valid (because it contains all the necessary information and in the correct hierarchal order for parsers to be able to work).


> (In the light of this discussion, I find it somewhat hard to understand 
> why some people insist on removing optional elements such as 
> 'requiredTests'.)

Several elements and attributes such as "requiredTests" are simply outside the scope of this Task Force and so we will not be using them. But since we are not maintaining TCDL or developing a spec here, it is not in our hands to remove any elements or attributes. In fact, we are merely agreeing on a minimal subset of vocabulary taken from TCDL and agreeing on how we will use them in this TF.

If we implement the extension points method then we are actually telling all the other applications that use TCDL (or other subsets of TCDL), that they must abide to our extension points in order to export metadata to our repository. For example, all the currently existing BenToWeb metadata files will not validate and will not be compatible with our repository.

However, if we employ the more flexible method described above then we allow full compatibility with TCDL. Granted, this makes validation more tricky and ugly but on the other hand one could just upload a BenToWeb metadata file and, for example, the Web front-end script should still be able to process it and generate an view of the metadata. We are not breaking or fragmenting TCDL.

IMO, It is actually a gentle way to acknowledge that other contexts and applications may have use cases for additional elements and attributes (such as "requiredTests") but that we are just not using these (for now).


>> A good example is the location pointers (see more background at the 
>> end of this mail): it just does not make sense to have to add the 
>> pointers in a completely different part of the XML tree (in the 
>> "Extension" part) instead of just extending the existing "locations" 
>> part of TCDL. Anyway, we need to decide on the extension model.
> 
> I can add more extension points (with 'Extension' etc) where you think 
> it would be necessary.

We could spend a lot of time trying to think of where to set extension points but we would then be trying to develop a spec. I think the extension points approach just doesn't make sense for *this* Task Force.


Regards,
  Shadi


-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe | 
Chair & Staff Contact for the Evaluation and Repair Tools WG | 
World Wide Web Consortium (W3C)           http://www.w3.org/ | 
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ | 
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ | 
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ | 
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France | 
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Wednesday, 20 September 2006 10:12:41 UTC