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

Re: extension model (was Re: TCDL Draft F)

From: Evangelos Vlachogiannis <evlach@aegean.gr>
Date: Wed, 20 Sep 2006 14:33:58 +0300
Message-ID: <45112726.3080909@aegean.gr>
To: TSDTF <public-wai-ert-tsdtf@w3.org>

Hi all,

 From my point of view XML Schema validator should be our friend. What I 
mean is that I think we should know where to find what in our meta (but 
also have extensibility options). From my poor experience, the idea of 
having "anything"/ "anywhere" really does not help especially during 
development. I think we should keep our friend (validator). On the other 
hand I really can see the need for an extension mechanism, but IMO this 
should be as "validator friendly" as possible.
So, my vote goes for 1) keeping "extension" element as optional 
(anyType) and 2) offer a strong core structure. In this way IMO the core 
structure will be short and clear and will not confuse developers. I 
would prefer having "extension" element at one place no matter where (no 
objection for current position).
Further to such an approach I would like to suggest being even more 
"validator friendly"?. What do you think of having an optional 
"namespace" attribute in "Extension" element that would specify the 
extension (application domain) schema (if there is one) so that the 
extension content could be validated as a separate document?  Then, we 
could probably have 1 or more "extension" elements with a schema or not.
Following such an approach, other (not core elements) like 
"requiredTests" could probably go under an extension.

Regards,
Vangelis

PS: Sorry if I add more problems here ?

Shadi Abou-Zahra wrote:
> 
> Hi,
> 
> 
> Christophe Strobbe wrote:
>>>> * there is now a chapter on the extensibility mechanisms;
>>>
>>> I quite strongly disagree with this extension model. IMO, parsers 
>>> should simply ignore elements and attributes they don't know, and let 
>>> the chaos have its way... ;)
>>
>> I don't understand why you disagree, unless you want to allow 
>> undefined elements and attributes *anywhere* in a TCDL file. This 
>> would require that I add xs:any (= any elements) before/after every 
>> defined element and that I add xs:anyAttribute to any element. Is that 
>> really what we want??
> 
> What is wrong with *any* additional elements and attributes to pop up 
> anywhere within the a TCDL file? As long as the required elements and 
> attributes exist and adhere to the basic restrictions (such as 
> cardinality restrictions etc) then a file should be deemed valid 
> (because it contains all the necessary information and in the correct 
> hierarchal order for parsers to be able to work).
> 
> 
>> (In the light of this discussion, I find it somewhat hard to 
>> understand why some people insist on removing optional elements such 
>> as 'requiredTests'.)
> 
> Several elements and attributes such as "requiredTests" are simply 
> outside the scope of this Task Force and so we will not be using them. 
> But since we are not maintaining TCDL or developing a spec here, it is 
> not in our hands to remove any elements or attributes. In fact, we are 
> merely agreeing on a minimal subset of vocabulary taken from TCDL and 
> agreeing on how we will use them in this TF.
> 
> If we implement the extension points method then we are actually telling 
> all the other applications that use TCDL (or other subsets of TCDL), 
> that they must abide to our extension points in order to export metadata 
> to our repository. For example, all the currently existing BenToWeb 
> metadata files will not validate and will not be compatible with our 
> repository.
> 
> However, if we employ the more flexible method described above then we 
> allow full compatibility with TCDL. Granted, this makes validation more 
> tricky and ugly but on the other hand one could just upload a BenToWeb 
> metadata file and, for example, the Web front-end script should still be 
> able to process it and generate an view of the metadata. We are not 
> breaking or fragmenting TCDL.
> 
> IMO, It is actually a gentle way to acknowledge that other contexts and 
> applications may have use cases for additional elements and attributes 
> (such as "requiredTests") but that we are just not using these (for now).
> 
> 
>>> A good example is the location pointers (see more background at the 
>>> end of this mail): it just does not make sense to have to add the 
>>> pointers in a completely different part of the XML tree (in the 
>>> "Extension" part) instead of just extending the existing "locations" 
>>> part of TCDL. Anyway, we need to decide on the extension model.
>>
>> I can add more extension points (with 'Extension' etc) where you think 
>> it would be necessary.
> 
> We could spend a lot of time trying to think of where to set extension 
> points but we would then be trying to develop a spec. I think the 
> extension points approach just doesn't make sense for *this* Task Force.
> 
> 
> Regards,
>  Shadi
> 
> 

-- 
Evangelos Vlachogiannis
Researcher - University of the Aegean
Contact&More: http://www.syros.aegean.gr/users/evlach/contactme.php
Received on Wednesday, 20 September 2006 11:34:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:33 GMT