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: 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@mulberrytech.com
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


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