- From: Tim Boland <frederick.boland@nist.gov>
- Date: Wed, 20 Sep 2006 09:51:54 -0400
- To: public-wai-ert-tsdtf@w3.org
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 [1]: http://www.w3.org/TR/qaframe-spec/#extensions At 12:09 PM 9/20/2006 +0200, you wrote: >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 13:52:51 UTC