Re: Two extensibility models

Hi all,

Here is an (untested) example of model A:

<formalMetadata>
  <!--// lots of TCDL elements and properties //-->
  <location>
    <earl:pointer>....</earl:pointer>
    <!--// lots of other pointers that are part of TCDL //-->
  </location>
</formalMetadata>
<Extension>
  <other:pointer>new type of pointer not in TCDL</other:pointer>
</Extension>


...and here is an example of model B:

<formalMetadata>
  <!--// lots of TCDL elements and properties //-->
  <location>
    <earl:pointer>....</earl:pointer>
    <!--// extensions are directly related to the parent //-->
    <other:pointer>new type of pointer not in TCDL</other:pointer>
  </location>
</formalMetadata>


Note that these are dummy elements and none of these examples would validate. However, they highlight the key difference between the two models. While model A validates *more easily* (model B can also be validated against a schema), it forces fixed extension points. If we don't put extension pointers in the right places now, we could end up having extensions out of context. For example if we don't have an extension point for the location pointers, and we find other types of pointers that we have not currently considered for TCDL.

We could spend time and effort trying to figure where we want to add extension points and probably end up adding them all over the place. This may be nearly the same effort (for the parsers, not the schema editor) as using model B. I may be wrong.

Regards,
  Shadi


Christophe Strobbe wrote:
> 
> 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
>>>
> 

-- 
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 Friday, 22 September 2006 08:01:20 UTC