- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Thu, 21 Sep 2006 22:24:42 +0200
- To: TSDTF <public-wai-ert-tsdtf@w3.org>
Hi Chris, At 21:50 21/09/2006, Chris Ridpath wrote: >Model 'A' makes the most sense to me because we can validate it. The >schema can always be changed later if there are other extensions that we need. > >I'm not sure I see the value of model 'B'. Could you provide a small >example that shows how it may be used? The use case is the following: someone outside the taskforce wants to use TCDL but wants to encode data for which we have defined no elements or attributes, so he adds his own elements and/or attributes (in another namespace). With model B, he can add those elements (and/or attributes) anywhere. If we had an application to process our own TCDL data, it would extract the TCDL properties that we know and ignore the ones that we don't know. Shadi, is that an accurate description of what you have in mind? Regards, Christophe >Cheers, >Chris > >----- Original Message ----- From: "Christophe Strobbe" ><christophe.strobbe@esat.kuleuven.be> >To: "TSDTF" <public-wai-ert-tsdtf@w3.org> >Sent: Thursday, September 21, 2006 3:21 PM >Subject: Two extensibility models > > >> >>Dear TF members, >> >>In the last conference call, we discussed the extensibility of TCDL. >>There are basically two models, which I will call model A and model B in >>the rest of this message. Next week, we will vote on the adoption of one >>of these models, which will then be implemented in the W3C XML Schema for >>TCDL. (This means that features of W3C XML Schema determine how >>extensions of TCDL can be defined.) >> >>Model A allows extensions only at certain predefined locations in the >>TCDL hierarchy. These locations allow an 'Extension' element that can >>contain only elements in TCDL's own namespace) and attributes in any >>namespace. After this optional 'Extension' element, other elements >>outside TCLD's own namespace can be used. This mechanism is rigid, but it >>makes sure that TCDL files with extensions still validate against the >>current XML Schema for TCDL. This is the model described in the current >>draft of the 'spec': >>http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Sep/att-0019/BenToWeb_TCDL_W3C_Submission_DraftF.html#chapt-extensibility. >>In the current draft, this model is only used in >>* 'formalMetadata' (for elements at the end of the content model of >>'formalMetadata' and attributes of 'formelMetadata), >>* 'preconditions' (for the content model), >>* 'questions' (for elements at the end of the content model, to allow >>other question types than those defined in TCDL), >>* 'requiredTests' (for elements at the end of the content model, to allow >>other types of testing or evaluation, and for attributes of 'requiredTests'), >>* 'location' (for attributes, so using EARL location pointers as >>attributes of 'location' is already possible!!), >>* 'testCaseDescription' (to allow 'Extension' and/or any elements from >>another namespace to be added after 'namespaceMappings', and for >>attributes of 'testCaseDescription'). >>A few more locations can be added, but in this model, they should only be >>added at the end of an existing branch instead of interleaving them with >>existing elements. >> >> >>Model B is to allow extensions anywhere, i.e. any new or unknown >>attributes and elements can appear anywhere in a TCDL file without >>causing validity errors. Since we don't want others to redefine TCDL >>behind our backs, these extensions cannot be in the same namespace as >>TCDL: they should be either in *any other namespace* or in a *namespace >>from a list that we define*. [This means that if we want our own >>(currently fictitious) TCDL 2.0 parser to be able to parse TCDL NG files >>that conform to a spec to be defined later by a Working Group, the newer >>TCDL NG can't add any elements or attributes in our own namespace. See >>the use case discussed by Shadi approximately two thirds down into the >>minutes: http://www.w3.org/2006/09/19-tsdtf-minutes.] >> >> >>Of course, there is also a model C (which I didn't mention): don't allow >>extensions at all. But that proposal was not on the table ;-) >> >> >>Please think about these models and comment on the list at least two >>hours before the next telephone conference. >> >> >>Best regards, >> >>Christophe Strobbe >> >> >> >>-- >>Christophe Strobbe >>K.U.Leuven - Departement of Electrical Engineering - Research Group on >>Document Architectures >>Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM >>tel: +32 16 32 85 51 >>http://www.docarch.be/ >> >>Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >> -- Christophe Strobbe K.U.Leuven - Departement of Electrical Engineering - Research Group on Document Architectures Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Thursday, 21 September 2006 20:24:55 UTC