Re: System properties

Colin Paul Adams wrote:
> >>>>> "Colin" == Colin Paul Adams <[email protected]> writes:
> 
> >>>>> "Michael" == Michael Kay <[email protected]> writes:
>     Michael> Yes, I think it often makes sense to make environment
>     Michael> variables accessible as system properties.
> 
>     Michael> I'd suggest implementations should provide a command line
>     Michael> option "make environment variables available as system
>     Michael> properties in namespace X" to give users the best chance
>     Michael> of writing portable code,
> 
>     Colin> In that case an exslt namespace would be the most portable.
>     Colin> E.g.
> 
>     Colin> http://exslt.org/environment-variables
> 
> Here's a rough specification for it:
> 
> Processors that claim support of EXSLT Environment-variables make the
> value of an environment variable name XYZ avialable via a call to
> 
> system-property (exslt-env:XYZ)
> 
> where the prefix exslt-env is bound to the namespace
> http://exslt.org/environment-variables 
> 
> As usual, any prefix that is bound to this namespace will do - the use
> of exslt-env as a prefix is purely illustrative.
> 
> The result of the call is dependent purely on the operating
> environment. However processors are encouraged to provide an option 
> where this system-property call returns the empty string, for security
> reasons. This option may be the default behaviour for the processor.
> 
> Notes: 
> 
> Most (all? - well, Linux at least! :-) operating systems treat 
> environment variable names in a case sensitive manner, so users are
> cautioned that the local-name is case-sensitive - fortunately this
> fits in with the definition of an XML lexical QName.
> 
> Normally, you can expect identical results with whatever processor you
> use (provided that it claims to support this module, and that the
> option is not turned off for security reasons) in a given operating
> environment.
> Note however, that it is possible that a processor might internally alter the set
> of enviroment name-value pairs, just like any other program.
> In order to conform to this module, the processor must document any
> alterations it makes to the set of name-value pairs in the
> environment.
> (Maybe it would be nicer to deny conformance in this case, I
> think. Opinions?)

I think that it is the processor's prerogative as to whether to expose
such modifications. I would guess that most implementers would not want
to bother keeping track of the original state of the environment, but
I suppose that leads to another question: should this be side-effect free?

If so, then environment variables should be exposed the same way
through the entire transformation. I'm not sure how side-effect free
anyone expects anything in EXSLT, or XSLT for that matter, to be these
days...

> Note that if a shell script is used to invoke an XSLT processor, that
> shell script might in itself change the set of name-value pairs. 
> In this case, no documentation is needed, as this is beyond the
> control of the XSLT processor.
> -- 
> Colin Paul Adams
> Preston Lancashire


+1 overall.

I would add:

Some operating systems store environment variables as encoded text, without 
any information about what encoding was used. The mapping of such data to an 
XPath string object is implementation-dependent.

-Mike