This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: keys and idrefs - XSLT2 request?
- To: XSL List <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] keys and idrefs - XSLT2 request?
- From: Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>
- Date: Tue, 09 Oct 2001 18:36:16 +0200
- Organization: ZKB
- Reply-To: xsl-list at lists dot mulberrytech dot com
"G. Ken Holman" <gkholman@cranesoftwrights.com> wrote
> At 01/10/09 13:05 +0100, DPawson@rnib.org.uk wrote:
> >Either to extend the key function in some way to handle idrefs,
> >or to permit a key definition to take in all attributes of type idrefs?
> >(I could see the problem where I have a CDATA attribute with spaces,
> >but surely idrefs are a bit special?)
>
> I've suggested tokenized access to the key tables in a letter to the XSL
> Editors a year ago (almost to the day). I've attached my contribution below.
IMHO it's unnecessary to incorporate a special handling of
IDREFS. At first, it would only work if there is a DTD/Schema
and the document is verified against it.
Further more, the problem could be solved quite pleasantly
using a properly designed tokenize() function, as Jeni suggested.
Such a function could be reused in many other contexts, like
for parsing ENITITIES attributes or arbitrary text nodes, while
a special handling of IDREFS is by definition less universal.
Last but not least, there is not really a big need for using
IDREFS. You can easily design a structure which will carry
the same information while being much more amenable to XSL
processing and practically all other tools dealing with XML:
<element idrefs="foo bar">
...
-->
<element>
<ref idref="foo"/>
<ref idref="bar"/>
...
Lets simply throw hardware (processor, bandwidth, disk capacity)
at the problem instead of raising the complexity of the software
dealing with your structures.
Badly designed XML structures are the source of much evil.
As a note: Stuff that could die in the next revision of the XML
standard (probably called SXML = Simplified XML :-)
- External entities. Use an element and XSL+document() or XLink.
- All other entities except character entities and standardized
entities representing character entities (like ä). XSL
processors might know (standardized) subsets of those standardized
entities, which would take care of the FAQ.
Anybody still using entities which are *not* representing character
entities? Use <def id="foo">FOO</def> ... <ref idref="foo"/>
instead of <!ENTITY foo "FOO"> ... &foo;
- Notations. Without entities, they are no longer necessary.
- ID, IDREF, IDREFS. Use key(). Every XML tool could implement an
equivalent, if not using it by XSLT. It could be part of a DOM
API, much like XPath could be.
- ENTITY, ENTITIES, NMTOKEN, NMTOKENS. Who cares?
Effects:
- Parsers could be easier and faster, especially when not validating,
because no entities get in the way.
- No need to read a DTD/Schema definition when not validating just
to get entities and IDs. Standalone handling of XML documents
becomes safer.
- A schema definition contains *only* logical structure definitions,
not some physical structure.
- External entity definitions no longer present a danger when
transporting XML documents to another environment.
Just my 20 mEUR. Thanks for your attention.
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list