This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: schema-1 (was something about keys, a long while ago)


David Carlisle wrote:

>>For us, just being able to code a simple "typed" match without jumping
>>through any syntactical hoops would certainly make the XSL easier to
>>understand and write.
>>
> 
> It's no fun at all if people take the opposite side of a debate from
> me and then make such plausible sounding arguments that there's a chance
> they might even be right...


No, and I can try to help!

While I think that powerful and expressive schema languages are a 
progress, I also think that imposing them would be a regression.

Schema languages are not that new and I am still thinking that one of 
the main progresses of XML over SGML is that DTDs are no longer mandatory!

And I think that it's important to make sure we can continue to perform 
XSLT transformations without defining first a schema.


> 
> However I'm still not toally convinced. It seems to me relatively rare
> to have lots of different element names (would have been called eleemnt
> types in an earlier era) which all have the same schema type and all
> need to be processed in the same way. If they have the same internal
> structure and the same processing one wonders what's gained by calling
> them different names.
> 
> Given that you do have lost of xxx-date element names you have to
> _somewhere_ mapo them all to date. You say you don't want a long list in
> a template match  (or equivalenty one assumes a lot of individual
> templates each calling a named "date" template) but the information has
> to be somewhere, for example in a list of type assignments in the
> schema, this doesn't seem so much easier to maintain.


No, and there could also be less disruptive ways of implementing this.


A schema validation, especially when it's creating a PSVI is nothing 
more than a transformation and instead of creating all this new APIs and 
complexity, I would have prefered if the W3C had used the existing 
infoset information items.

The datatype, for instance, could have been considered (at least for 
elements) as a xsi:type attribute added by the validation.

If it had been the case, matching all elements of type foo:date would 
just have been a match="*[@xsi:type='foo:date']" (with the issue of 
supporting QNames in XPath/XSLT which needs to be fixed anyway).

The case of attributes would have been more touchy (maybe the attributes 
were really a bad idea in XML, after all) but I am convinced we could 
find a way to express the PSVI by adding elements and attributes in a 
specific namespace instead of creating new information items...

Eric


> David
> 
> _____________________________________________________________________
> This message has been checked for all known viruses by Star Internet
> delivered through the MessageLabs Virus Scanning Service. For further
> information visit http://www.star.net.uk/stats.asp or alternatively call
> Star Internet for details on the Virus Scanning Service.
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
> 
> 
> 



-- 
Rendez-vous à Paris pour une visite guidee de la nebuleuse XML.
                                           http://dyomedea.com/formation/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]