[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: use cases for d-o-e

Subject: Re: use cases for d-o-e
From: David Carlisle <davidc@xxxxxxxxx>
Date: Fri, 11 Jan 2002 10:50:40 GMT
Re:  use cases for d-o-e
> I guess I was thinking more in the case of situations(these being
> the kinds where I normally use them) where you have an entity built up of
> other entities, which when expanded produces not just text but a number of
> nodes for example. Never having given it much thought I just figured there
> might be a process of optimization whereby the parser could save some power
> in cases where entities lead to nodesets

yes I've posted some of my entity definitions like that to this list
before (which is why Joerg explictly barred me (in fact the whole of
NAG:-) from taking part in this thread:-)

But that's what I meant can not directly work in the case of namespace
aware parsers.

If you have
<!ENTITY widget "<a:b> ... <x:y/> ... </a:b>" >

then the namespace bindings for a: and x: are not known at the time of
the entity definition and might be different if you use &widget; in two
different places. thus you can't parse the replacement text into a
fragment of infoset or xpath data model which can be quickly inserted
whenever the reference is used. You either have to keep it as a
string or parse it into some kind of "flexible" tree structure that
allows the namespace names to be fixed up later. In either case you
need to re-parse the string or walk over your tree when the entity
reference is used, so probably not saving a lot of time compared to
parsing the document without entities in which the strings are
duplicated. (maybe systems can do some fancy optimisations here,
but they may be able to do other optimisations as well, what I'm arguing
is that entity references don't directly save you from reparsing the
same string multiple times.

I don't know what implementations do (except mine, which keeps
everything as strings anyway, seing as it's not written in a language
that supports anything else).

MSXML does parse the entity replacement text into namespace aware DOM
and so fatally barfs on a definition such as the above and forces users
to go

<!ENTITY widget "<a:b xmlns:a='..' xmlns:x='...'> ... <x:y/> ... </a:b>" >

thus ensuring the prefixes have bindings known at the point of
definition (and consistent wherever the entity is used).

This restriction doesn't conform with the namespace rec (but I don't
think the evil empire care:-)

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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.