From 0a2faf3d78ce5afd9d8c50eeef44798f69444432 Mon Sep 17 00:00:00 2001 From: Norman Walsh Date: Fri, 12 Apr 2024 18:45:29 +0100 Subject: [PATCH 1/2] Attempt to clarify the semantics of static options --- xproc/src/main/xml/specification.xml | 37 +++++++++++++++++++++------- 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/xproc/src/main/xml/specification.xml b/xproc/src/main/xml/specification.xml index 35425f17f..ed6430483 100644 --- a/xproc/src/main/xml/specification.xml +++ b/xproc/src/main/xml/specification.xml @@ -3025,15 +3025,34 @@ Variable names are always expressed as
Static Options - A p:option may be declared “static”; options declared within a p:library must - be static. - It is a static error if options that are the direct children of - p:library are not declared “static”. - The values of static options are computed during static - analysis. - - XProc defines a single, global scope for static options. Every static option must have exactly one - in-scope declaration. + A p:option may be declared “static”; options declared + within a p:library must be static. + It is a static error if + options that are the direct children of p:library are not + declared “static”. + + The values of static options are computed during + static analysis. Consequently, expressions which + initialize static options may not refer to the context item, variables, or + other options that are not static. + + Every static option must have exactly one in-scope declaration. + It is + a static error if the qualified name of a static option + shadows + the name of another static option. + + It is not an error if two static options with the same name appear + in different scopes, but it is not good practice. Bear in mind, for + example, that if the implementation provides a mechanism for specifying + default values for static options at compile time, the value provided for + any option must satisfy the type specified on every static option declaration + with that name. Any mechanism for specifying default values for static options + applies equally to options whether they are public or private. + + Libraries that define static options, especially private ones, are + encouraged to use namespaces so that collision with the names of options in + the calling pipeline, or other imported libraries are unlikely.
From fc6cdb87cd972588c32cd46839e551c72668f424 Mon Sep 17 00:00:00 2001 From: Norman Walsh Date: Tue, 28 May 2024 17:57:32 +0100 Subject: [PATCH 2/2] Fixed err:XS0088 per a suggestion from Achim --- xproc/src/main/xml/specification.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xproc/src/main/xml/specification.xml b/xproc/src/main/xml/specification.xml index ed6430483..b27c86914 100644 --- a/xproc/src/main/xml/specification.xml +++ b/xproc/src/main/xml/specification.xml @@ -3040,7 +3040,7 @@ Variable names are always expressed as It is a static error if the qualified name of a static option shadows - the name of another static option. + the name of another static option or a variable. It is not an error if two static options with the same name appear in different scopes, but it is not good practice. Bear in mind, for