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

RE: keys and idrefs - XSLT2 request?

Subject: RE: keys and idrefs - XSLT2 request?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 10 Oct 2001 11:41:13 -0400
RE:  keys and idrefs - XSLT2 request?
At 03:59 AM 10/10/01, DaveP wrote:
Wendell wrote:
> I think it'd be a tall order to get much consensus on IDREFS being so
> special that the definition of key() should be stretched that
> far (even
> broken, since it makes its functionality very different
> depending on a
> DTD's being parsed). This would be a source of much
> confusion, I imagine,
> and also complaints since many users simply wouldn't
> understand or accept
> the rationale for the design.

Which makes them exactly on a par with id attributes vs ID attributes?
Don't tell me you've never been puzzled by missing cross references
when you don't have the DTD to hand?

1. No need to take something that users already find confusing as a precedent, is there?


2. The distinction between attributes named 'id' and attributes of type ID has an impact on the id() function, which users unfamiliar with the ID mechanism find confusing. But id() has no other use besides resolving cross-references. key() has many other uses (significantly, grouping). Especially given the powerful but subtle feature of a key declared with a node set as its 'use' attribute, or a key() function called with a node set as its second argument, keys are already a bit steep on the learning curve (though in this case the tradeoff is well worth it). So I'd be very reluctant to mess with the key mechanism as it stands, if there are other approaches.

3. I think the WG -- and Jeni -- with their alternatives, have already made this debate moot! :-)

I ought to start an faq section entitled come here when you're desperate.
I could include Mike Kays subtleties on namespaces,
missing/mistyped namespaces in a stylesheet, lack of DTD with screwed
up cross references etc.

I'm sure there are more.

Yes, there are always more!


Anyway, that's why IDREFS make a special case, despite our many users
of well formed not valid XML.

I agree that IDREFS make a special case, but consider a need to change the way key() works to be a non sequitur. Also, as a general principle I think it's good to keep DTD dependencies to an absolute minimum. (This is coming from a user in whose world DTDs are very useful: unlike Mike K. I *like* DTDs.) We'll have plenty enough to worry about with post-schema-validation-infosets!


Cheers,
Wendell


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================


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.