Re: Two extensibility models

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?

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
>
>

Received on Thursday, 21 September 2006 19:51:29 UTC