W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > September 2006

Two extensibility models

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Thu, 21 Sep 2006 21:21:44 +0200
Message-Id: <>
To: TSDTF <public-wai-ert-tsdtf@w3.org>

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

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

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Thursday, 21 September 2006 19:22:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:00 UTC