Re: adding a namespace declaration to result stylesheet?

Oliver Becker wrote:

>Yes, the namespace axis is deprecated in XPath 2.
>That means we need different metastylesheets for XSLT-based implementations.
>  
>
Does anyone know the current progress of XPath 2 and XSLT2?  
I was toying with the idea of making it the default for ISO Schematron,
but I am having to finish the spec in the next fortnight, so unless it
XSLT 2's XPaths will be set in stone really soon I will have to go with 
XSLT 1.

>XPath expressions that select elements from a certain namespace must use
>prefixed names. If the targetted elements are in the null (empty) namespace
>then clearly no prefix must be used.
>  
>
Yes. But people often expect namespaces to bind the same on the 
elements, attributes and
attribute values, whereas they have different rules.  Most confusion 
people have about
<ns> often turns out to be about getting default qualification of 
unprefixed names in
XPaths; they would have the same issue with the XSLT-style rules.

>The question is if Schematron needs this additional <ns> element to
>declare namespaces. I don't think so. I cannot remember why <ns> was 
>introduced:
>- because nobody was aware of <xsl:copy-of select="namespace::*" /> ?
>- because this solution didn't work with some XSLT processors?
>
>Do you see any (semantic) difference between
><schema xmlns:p="urn:my-personal-namespace" ...>
>and
><schema ...>
>  <ns uri="urn:my-personal-namespace" prefix="p" />
>
Well, I don't think there is a necessary semantic difference. A language 
is free to define
what the values of an attribute means, including how other values in the 
document bind
to it.  TAG discussed whether namespaces apply to attribute values, and 
they ended up
deciding it was a language-dependent issue.  XPointer can have explicit 
schemes as
part of the URL, XSLT can use XML namespace declarations, WXS can have
its Krazy rules concerning qualification, and Schematron is free to use 
explicit declarations.

Using XML Namespaces doesn't really gain any convenience, because all 
the APIs are not
inheritance-aware: if I cut out an attribute value in DOM and transplant 
it elsewhere,
I have to search for the in-scope namespace declarations anyway.  All it 
would gain
would be that Schematron would act more the way that XSLT acts, but I 
want to
hide XSLT from people not expose it.

I think XML Namespace  is positively harmful for XPaths in Schematron, 
because
of being able to redefine prefixes during the course of a schema.  All 
those kind of
scoping effects complicate understanding and implementation; if XML 
namespaces
allowed us to barf when prefixes were re-defined, or forced us to only use
global headers it would be much better.  But what is true in the small 
may be
cumbersome in the large: adding <libary> (or some other higher-level 
function)
may have different trade-offs:-- viz. it might be useful to be able to 
have locally
scoped prefixes.   (I personally don't think so.)

(Another potential reason for having <ns> explicit is that then it could 
have documentation
elements attached.  We haven't gone that way.)

So ultimately the justification is really just that I think it the 
simplest and safest approach,
for writing, implementation and understanding.

(Eddie Robertsson's embedded Schematron takes the currently defined 
namespaces
from its context, rather than needing explicit <ns> elements.  I am not 
sure whether
it uses the xmlns: declarations or the WXS attributes.  )

Cheers
Rick

P.S. Does this actually need to be a choice?  Another possibility would 
be to allow both
<ns> *and* xmlns: (with XSLT rules) so that users could decide what they
wanted. 






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf