Could xsl:variable be defined twice with same name in same scope.
For code similar to the following:
<xsl:template match="\">
<table>
<tr><td>
<xsl:variable name="status" select="normal"/>
</td></tr>
<tr><td>
<xsl:variable name="status" select="failed"/>
</td></tr>
</table>
</xsl:template>
Maybe it depends on browse's type. What is the standard?
First, two variables never have the same scope. Even if they are both global, the scope of the variable excludes its own select expression, so the scope of the two variables is different.
Second, in your example the scope of the two variables isn't even overlapping. Each variable is confined to its own containing td element.
For two global variables, the rule is that you can have two variables with the same name provided they have different import precedence, in which case all references are treated as references to the one with higher precedence.
If one variable is local and the other is global, then the local variable wins if it is in scope.
If you have two local variables with overlapping scope, this is an error in XSLT 1.0, but is permitted in XSLT 2.0; within the overlap area, the variable with smaller scope wins.
It is an error if two or more top-level variables (outside any template) have the same name.
Similarly it is an error if two or more variables within the same template have the same name.
But it is allowable for a variable within a template to shadow a variable of the same name at the top level.
There is no clash between variables unless their scopes (the parts of the stylesheet where the variables are visible) overlap. The scope of a variable inside a template includes its following sibling elements and their descendants. The scope of a top-level variable is everywhere in the stylesheet after that variable.
I have found the key.
MSXML 3.0 supports only XDR schemas, it does not support XSD schemas. MSXML 4.0, MSXML 5.0, and MSXML 6.0 support XSD schemas.
Related
I have environmental variable called ENV, which holds the DEV,QA OR PROD region as value. When the server.xml loaded it includes the corresponding db configuration using this variable. For ex: db-config-${env.GAH_ENV}.xml
I would like to pass the same value to the batch job xml as a job parameter or properties to any of the class. How Can I do that.
below code snippet not working
<property name="environment" value="${env.GAH_ENV}"/>
The short answer is that using a batch property may not be a good solution and you might consider something else like MicroProfile's #ConfigProperty.
The reason is there's not a built-in way to access environmental variables through JSL substitution. There is also not a convenient way for one artifact to set a property value to be used by a second artifact running later within the job execution.
In the special case that you are starting the job from within the same JVM it will execute, of course, you could pass the env var value as a job parameter.
But in the general case, if you can change the Java code and you don't really need a batch property I would use a MicroProfile Config property instead, injected via #Inject #ConfigProperty.
By doing so you lose the batch-specific substitution precedence, including the override available via job parameters passed with the submit/start. You also give up the ability to use this property in other JSL substitutions (to "compose" its value into other batch properties via other substitutions).
But you at least get a property with its own various levels of precedence/override (e.g. server config, env var, microprofile-config.properties), which is more flexible than just always reading the env var via System.getenv( ).
This is certainly an area to consider for the next version of the (now-Jakarta) Batch spec.
Suppose I have the following instantiation
first_mux_input=top.middle.down[i];
second_mux_input=top.middle.down[i+1];
assign down = (select[i])? first_mux_input:second_mux_input;
supposing there are a lot of muxes and their outputs go to the inputs to muxes that are placed below them.
I'm using the variable "down" before I define it. is this legal since verilog compiles all the lines subsequently and not by order(in this case)?
thanks
The assign statement is not a declaration. A declaration would be:
wire down;
If you never declare down such as this, it will be implicitly declared.
Section 6.10 of IEEE 1800-2012 states:
If an identifier appears on the left-hand side of a continuous assignment statement, and that identifier
has not been declared previously in the scope where the continuous assignment statement appears or
in any scope whose declarations can be directly referenced from the scope where the continuous
assignment statement appears (see 23.9), then an implicit scalar net of default net type shall be
assumed. See 10.3 for a discussion of continuous assignment statements.
and then:
See 22.8 for a discussion of control of the type for implicitly declared nets with the `default_nettype
compiler directive.
This (I believe) typically means a wire in Verilog and logic in SystemVerilog.
Now, as far as using the value before it is assigned, that's perfectly legal. As long as not declared after it is used or assigned.
It depends on your synthesizer. I have worked only with Xilinx. In my case Xilinx accepts this type definition for simulation. But for synthesis you need to define a wire/reg before instantiation.
`<xsl:template match="xhtml:style">
<xsl:variable name="text" select="text()"/>
</xsl:template>`
This is my template having local variable whose value would be the internal styles of html and i want these internal style data to be a global variable value so that i could access this value in other templates for further processing.
I want to use internal styles data for further processing so i think of using this approach.
How could i insert value to global variable from local variable of a template.???
How could i insert value to global variable from local variable of a
template.???
This is a FAQ -- you can't.
XSLT is a functional programming language and among other things this means that a the value of a variable, once defined, cannot be modified.
You can achieved what you want in a much simpler way -- define the wanted global variable simply as (a child of `xsl:stylesheet'):
<xsl:variable name="vYourGlobalVar" select="(//xhtml:style)[1]/text()"/>
I am wondering if there exists already some naming conventions for Ocaml, especially for names of constructors, names of variables, names of functions, and names for labels of record.
For instance, if I want to define a type condition, do you suggest to annote its constructors explicitly (for example Condition_None) so as to know directly it is a constructor of condition?
Also how would you name a variable of this type? c or a_condition? I always hesitate to use a, an or the.
To declare a function, is it necessary to give it a name which allows to infer the types of arguments from its name, for example remove_condition_from_list: condition -> condition list -> condition list?
In addition, I use record a lot in my programs. How do you name a record so that it looks different from a normal variable?
There are really thousands of ways to name something, I would like to find a conventional one with a good taste, stick to it, so that I do not need to think before naming. This is an open discussion, any suggestion will be welcome. Thank you!
You may be interested in the Caml programming guidelines. They cover variable naming, but do not answer your precise questions.
Regarding constructor namespacing : in theory, you should be able to use modules as namespaces rather than adding prefixes to your constructor names. You could have, say, a Constructor module and use Constructor.None to avoid confusion with the standard None constructor of the option type. You could then use open or the local open syntax of ocaml 3.12, or use module aliasing module C = Constructor then C.None when useful, to avoid long names.
In practice, people still tend to use a short prefix, such as the first letter of the type name capitalized, CNone, to avoid any confusion when you manipulate two modules with the same constructor names; this often happen, for example, when you are writing a compiler and have several passes manipulating different AST types with similar types: after-parsing Let form, after-typing Let form, etc.
Regarding your second question, I would favor concision. Inference mean the type information can most of the time stay implicit, you don't need to enforce explicit annotation in your naming conventions. It will often be obvious from the context -- or unimportant -- what types are manipulated, eg. remove cond (l1 # l2). It's even less useful if your remove value is defined inside a Condition submodule.
Edit: record labels have the same scoping behavior than sum type constructors. If you have defined a {x: int; y : int} record in a Coord submodule, you access fields with foo.Coord.x outside the module, or with an alias foo.C.x, or Coord.(foo.x) using the "local open" feature of 3.12. That's basically the same thing as sum constructors.
Before 3.12, you had to write that module on each field of a record, eg. {Coord.x = 2; Coord.y = 3}. Since 3.12 you can just qualify the first field: {Coord.x = 2; y = 3}. This also works in pattern position.
If you want naming convention suggestions, look at the standard library. Beyond that you'll find many people with their own naming conventions, and it's up to you to decide who to trust (just be consistent, i.e. pick one, not many). The standard library is the only thing that's shared by all Ocaml programmers.
Often you would define a single type, or a single bunch of closely related types, in a module. So rather than having a type called condition, you'd have a module called Condition with a type t. (You should give your module some other name though, because there is already a module called Condition in the standard library!). A function to remove a condition from a list would be Condition.remove_from_list or ConditionList.remove. See for example the modules List, Array, Hashtbl,Map.Make`, etc. in the standard library.
For an example of a module that defines many types, look at Unix. This is a bit of a special case because the names are mostly taken from the preexisting C API. Many constructors have a short prefix, e.g. O_ for open_flag, SEEK_ for seek_command, etc.; this is a reasonable convention.
There's no reason to encode the type of a variable in its name. The compiler won't use the name to deduce the type. If the type of a variable isn't clear to a casual reader from the context, put a type annotation when you define it; that way the information provided to the reader is validated by the compiler.
In programming (and math) there are variables and constants. Is there a name to describe both of them?
I was thinking value, but that's not it. A value is what variables/constants contain, not what they are.
I would call it a symbol. From google:
sym·bol/ˈsimbəl/Noun
1. A thing that represents or stands for something else,
esp. a material object representing something abstract.
...
From what I know Its called a field
How about:
maths and logic: term
programming: l-value and r-value.
There are a few different terms I use, depending on context. I'll give you a list of the terms I (might) use - sometimes I'll just default to calling everything 'variables'.
Field - a variable or constant that's declared as part of the class definition.
Parameter - one of the inputs specified when defining a method in a class.
Argument - the actual value that you provide for a parameter when calling a method.
Method variable - a variable declared inside a method.
Method constant - a constant declared inside a method.
In OOP, the attribute can be both a variable and a constant.
Identifiers
In computer languages, identifiers are tokens (also called symbols) which name language entities. Some of the kinds of entities an identifier might denote include variables, types, labels, subroutines, and packages.
Symbols are super set of Identifiers
https://en.wikipedia.org/wiki/Identifier#In_computer_languages
How about "data item"?
One definition: https://www.yourdictionary.com/data-item
Example showing it can be used for local variables/constants as well (unlike "field" or "attribute"): https://www.microfocus.com/documentation/visual-cobol/VC222/EclWin/GUID-A3B817EE-1D63-4F67-A62C-61DE681C6719.html