Re: extension model (was Re: TCDL Draft F)

The "Quality Assurance Framework: Specification Guidelines" (QA SpecGL) 
address the topic of extensibility in section 2.4.3 "Extensibility and 
Extensions" [1] in "Requirement 11: Address Extensibility".   Although this 
requirement as stated in QA SpecGL applies to specifications, are there any 
ideas in [1] that would help the Task Force address extensibility in the 
context of the Task Force?

Thanks and best wishes
Tim Boland NIST


At 12:09 PM 9/20/2006 +0200, you wrote:

>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.
>  Shadi
>Shadi Abou-Zahra     Web Accessibility Specialist for Europe | Chair & 
>Staff Contact for the Evaluation and Repair Tools WG | World Wide Web 
>Consortium (W3C)  | Web Accessibility 
>Initiative (WAI), | WAI-TIES 
>Project,       | Evaluation and 
>Repair Tools WG, | 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 13:52:51 UTC