Subject: RE: [xsl] 2.1 Must Allow Matching on Default Namespace Without Explicit Prefix From: "Evan Lenz" <elenz@xxxxxxxxxxx> Date: Wed, 21 Feb 2001 12:35:43 -0800 |
Steve Muench wrote: > To someone like yourself who is an XSL veteran, it may > never be a mistake that you make, or the workaround is > so burnt into your brain that you don't think twice about it, > but the WG perceived this issue as a major "learnability" hurdle. Interesting... Now, it will be a learnability hurdle for those of use who have already learned. But I certainly hope we'll be in the minority :) Of course, I think they might be equally frustrated by the fact that, in order to generate a result that's *not* in a namespace, they will have to insert xmlns="" on their literal result elements. It's all a matter of perspective, I suppose. It might be worth noting that such confusion probably only arises when the source document uses a default namespace, as in your example, which technically is orthogonal to whether the stylesheet uses a default namespace or not. <sidenote> The root of this confusion is what many have called a design flaw in XSLT, namely the mapping of namespace prefix mappings to the in-scope namespace declarations. I believe that DOM implementations are allowed to arbitrarily change prefixes, because that supposedly would not change the meaning of the document for applications.....except for XSLT stylesheets. I can't come up with a better solution, and that's probably not going to change. I'm not sure that I'd want it to anyway. </sidenote> But you still didn't answer my question. Will the default namespace be used to evaluate XPath expressions? I know they're different specs, but I think inconsistency there would cause even more confusion. I like the rule in XPath that says anything in a namespace has to have a prefix. Yeah it's different than the case with XML Namespaces, but it's a handy thing to be able to immediately recognize whether a name test is in a namespace or not. I could cope with this change, but it seems like it would cause a fairly significant backward compatibility headache. Evan Lenz XYZFind Corp. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] 2.1 Must Allow Matching o, Steve Muench | Thread | Re: [xsl] 2.1 Must Allow Matching o, Steve Muench |
Re: [xsl] Conditional [AND] [OR] te, Stephen Cunliffe | Date | [xsl] [ANN] RenderX XEP 2.21 Releas, Nikolai Grigoriev |
Month |