Re: Two extensibility models

At 10:01 22/09/2006, Shadi Abou-Zahra wrote:

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

The above would not validate, because 'location' currently allows no
child elements, but that could be changed to allow child elements in
other namespaces. Extension can only have child elements in the
TCDL namespace, but attributes in any namespace.


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

With model A, the idea is not to add extension points all over the place, 
but only at the end of a branch,
like so (with prefixes everywhere for clarity):
<tcdl:A>
   <tcdl:B />
   <tcdl:C />
   <tcdl:D>
     <tcdl:E />
     <tcdl:F />
     <tcdl:Extension>
       <tcdl:monty />
       <tcdl:python />
     </tcdl:Extension>
     <other:parrot />
   </tcdl:D>
   <tcdl:Extension>
     <tcdl:spam />
     <tcdl:eggs />
   </tcdl:Extension>
   <earl:grey />
</tcdl:A>

But not:
<tcdl:A>
   <tcdl:B />
   <tcdl:C />
   <tcdl:D>
     <other:parrot /><!-- non-TCDL namespace -->
     <tcdl:E />
     <tcdl:Extension><!-- Extension not allowed here-->
       <it:monty /><!-- non-TCDL namespace -->
       <tcdl:python />
     </tcdl:Extension>
     <tcdl:F />
   </tcdl:D>
   <tcdl:Extension>
     <tcdl:spam />
     <tcdl:eggs />
   </tcdl:Extension>
   <earl:grey />
</tcdl:A>

Best regards,

Christophe


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

-- 
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 Monday, 25 September 2006 12:36:19 UTC