I need to solve this and looks like I need help.
Here is the problem definition
We have an existing schema X [X is an industry standard schema] for which we are building some extensions in a new schema Y (with a different target namespace].
Now the problem is we want to restrict usage of the elements/attributes of Schema Y to be only as members of defined elements/types of X. [schema validation should fail in case of invalid usage].
How do we achieve this? What is the best way to do this?
RM
I'd say it depends on how much you are modifying and what the schemas look like. One aspect will be if your extensions are near the root or near the leafs.
Here is a general approach for near the root.
X.xsd
element name=foo type=fooType
complexType fooType
sequence
element name=bar type=BarType
Y.xsd
import X.xsd namespace=xns
element name=foo type=foo2Type
complexType foo2Type
sequence
element name=bar type=xns:BarType
element name=baz type=BazType
here you have added a new element baz of your own definition but bar will contain all the children required by the industry standard.
Import X into Y (with the import element).
Related
I am trying to extend the geo.StreetSuffix enum to include some more possible values. It currently doesn't have a value for Greene which is a valid street suffix. This is what my concept looks like:
enum (StreetSuffix) {
description (Street Suffix)
extends(geo.StreetSuffix)
symbol (Greene)
}
This is a training sample:
[g:Evaluate:prompt] (19)[v:geo.StreetNumber] (Fake Hills)[v:geo.StreetName] (Lane)[v:StreetSuffix:Lane]
When I do this though the training files give me the following error:
Confusion Points: Match(es) on : "Lane". and the language recognition no longer works for that value. Am I doing something wrong here, is there a bug, or is this not how Enum inheritance is supposed to work?
I am happy to write my own enum which would be a copy of geo.StreetSuffix but it seems like a waste if I could just extend it and add some of my own values.
Unfortunately, you'd have to copy everything from the old vocab file (which you don't have access to).
Note
If you extend a type into another capsule, a new vocabulary file must still be created. Vocabulary is never inherited, even if you use extends or add role-of to a model.
https://bixbydevelopers.com/dev/docs/dev-guide/developers/training.vocabulary#adding-vocabulary
That being said, you can file a ticket with support to add Greene and any other missing values you might come across...
I am trying to programmatically access all fields of some Python3 object using a combination of dir and getattr. Pseudocode below:
x = some_object()
for i in dir(x):
print(str(getattr(x, i)))
However, the Python docs (https://docs.python.org/2/library/functions.html#dir) on dir is VERY vague:
Note Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases.
My questions:
1) Is there a way to achieve the above more rigorously than using dir?
2) What does "interesting set of names" mean and how is it computed?
Kind of?
With custom __getattr__ and __getattribute__ implementations, an object can dynamically respond to requests for any attribute. You could have an object that has every attribute, or an object that randomly has or doesn't have the foo attribute with 50% probability every time you look at it. If you know how an object's __getattr__ and __getattribute__ work, and you know that they respond to a finite list of attribute names, then you can write your own version of dir that lists everything, but even handling the basic built-in types requires an uncomfortable number of cases. You can see the dir implementation in Objects/object.c.
The documentation gives an explanation of which attributes are considered interesting:
If the object is a module object, the list contains the names of the module’s attributes.
If the object is a type or class object, the list contains the names of its attributes, and recursively of the attributes of its bases.
Otherwise, the list contains the object’s attributes’ names, the names of its class’s attributes, and recursively of the attributes of its class’s base classes.
By "attributes", this documentation is mostly referring to the keys of its __dict__. There's also some handling for __members__ and __methods__; those are deprecated, and I don't remember what they do.
I have created the dependency graph for my scenario that takes a text input.
SemanticGraph dependencies = sentence.get(CollapsedCCProcessedDependenciesAnnotation.class);
I am successful in getting the "num" modifier dependency using the following code:
List<SemanticGraphEdge> edgesContainingNumModifierDependency = dependencies.findAllRelns(GrammaticalRelation.valueOf("num"));
However, I want to find the edges pertaining to the "root" and hence, the following
List<SemanticGraphEdge> edgesContainingRootModifierDependency = dependencies.findAllRelns(GrammaticalRelation.valueOf("root"));
does not seem to work.
Can anyone explain why? And how I can get the edge for root?
We don't actually store a SemanticGraphEdge between the root word and a dummy ROOT node. (You can see that the dependency is manually tacked on in public-facing methods like toList).
From the SemanticGraph documentation:
The root is not at present represented as a vertex in the graph. At present you need to get a root/roots from the separate roots variable and to know about it. This should maybe be changed, because otherwise, doing things like simply getting the set of nodes or edges from the graph doesn't give you root nodes or edges.
You might be able to get what you want, though, with SemanticGraph#getFirstRoot.
Our service contract is composed of a wsdl file (W) and several XSDs (A,B,C).
Basically W refers to A, which is just an empty schema that imports B and C.
Our client claims that such structure is against the W3C specs and that B and C must be explicitly imported by W.
Our solution validates against XML Spy, SOAP UI and works well with Java.
Do you know if their claim is correct?
In fact it seems that it does violate the XSD spec. Apparently, if:
schema A refers to schema B and C it does not matter whether schema B imports schema C or not, A must import B and C.
At least, that's what I have found googling around and the W3c specs seem to say so as well.
I want to see if I can map Racket structure fields to columns in a DB.
I've figured out how to extract accessor functions from structures in PLT scheme using the fourth return value of:
(struct-type-info)
However the returned procedure indexes into the struct using an integer. Is there some way that I can find out what the field names were at point of definition? Looking at the documentation it seems like this information is "forgotten" after the structure is defined and exists only via the generated-accessor functions: (<id>-<field-id> s).
So I can think of two possible solutions:
Search the namespace symbols for ones that start with my struct name (yuk);
Define a custom define-struct macro that captures the ordered sequence of field-names inside some hash that is keyed by struct name (eek).
I think something along the lines of 2. is the right approach (define-struct has a LOT of knobs and many don't make sense for this) but instead of making a hash, just make your macro expand into functions that manipulate the database directly. And the syntax/struct library can help you do the parsing of the define-struct form.
The answer depends on what you want to do with this information. The thing is that it's not kept in the runtime -- it's just like bindings in functions which do not exist at runtime. But they do exist at the syntax level (= compile-time). For example, this silly example will show you the value that is kept at the syntax level that contains the structure shape:
> (define-struct foo (x y))
> (define-syntax x (begin (syntax-local-value #'foo) 1))
> (define-syntax x (begin (printf ">>> ~s\n" (syntax-local-value #'foo)) 1))
>>> #<checked-struct-info>
It's not showing much, of course, but this should be a good start (you can look for struct-info in the docs and in the code). But this might not be what you're looking for, since this information exists only at the syntax level. If you want something that is there at runtime, then perhaps you're better off using alists or hash tables?
UPDATE (I've skimmed too quickly over your question before):
To map a struct into a DB table row, you'll need more things defined: at least hold the DB and the fields it stand for, possibly an open DB connection to store values into or read values from. So it looks to me like the best way to do that is via a macro anyway -- this macro would expand to a use of define-struct with everything else that you'd need to keep around.