Re: Environment Variable Retrieval Spec

John L. Clark wrote:

>Let's get the specs rolling again, shall we?
>
>I've taken a shot at a simple spec for the namespace that will allow
>conforming implementations to retrieve environment variables using the
>`system-property` function, based upon Colin Paul Adams' original
>request[0] and the subsequent discussion.
>  
>

looks good, language just needs a little tweaking IMHO will attempt a
redraft tommorow.

>As this is neither an extension function nor an extension element, I
>included the specification of this mechanism directly in the body of the
>module's description.  This is also the introduction of the 'System'
>module, which currently only contains this namespace specification.
>  
>

as for usability perhaps we should consider expanding upon or
standardizing the idea of module variables / properties?  This would
also have an impact in definition of dist (functions, elements, and new
variables directory).

other modules may take advantage of this, though we need to be careful
of defining the difference between a variable and a function, e.g. do we
ever see something like

|    system-property('date:now')|

or perhaps more appropriate would be something like

    system-property('date:locale')

personally I wouldnt like such a convention being applied to constants
and variables e.g.

    system-property('math:pi')

maybe we should limit side effects and constrain such things by simply
saying that such variables are immutable during an xslt process...or
something along these lines.

since we are referring to another namespace in the string for the
system-property call, can't we go one more step and just expose as a
proper xsl param/variable?

    <xsl:value-of select="$env:User"/>

not pining to expand things, just food for thought/debate.

cheers, Jim Fuller