[
Lists Home |
Date Index |
Thread Index
]
"Dare Obasanjo" <dareo@microsoft.com> writes:
> I think Jeni did a good job clearing up your misconceptions. However
> there is one problem with xsi:type which has been bothering me for the
> past couple of days. The xsi:type screws up the kind of type aware
> processing that will be enabled with XQuery and XSLT.
>
> With XQuery and XSLT one can attempt to process elements based on their
> XSD types but with xsi:type one can both restrict and extend these types
> in the instance document unbeknownst to the author of the processing
> code. At first glance it seems like both these mechanisms do not
> radically alter the content model in such a manner that carefully
> written type aware processors will be rendered ineffective.
That was certainly the goal. If you _do_ depend only required
sub-parts/attributes, and _don't_ access sub-parts by working backwards
from the end, you will always win regardless of xsi:type.
ht
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2002, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
|
