What is the relationship between:
the import element in WSDL
-and-
the import element and in XML Schema
... and in particular the relationship between the location attribute of the former and the schemaLocation attribute of the latter?
Though I can use a catalog file (in a JAX-WS / wsimport toolchain) to "override" schemaLocation attributes for the xsd:import element it seems that I can't do the same for the location attributes of the wsdl:import statement.
In both cases, the import establishes a relationship between a document (be that WSDL or XSD) and an external resource).
Barring the confusion which surrounded the wsdl:import, specifically if it could be used to import XSDs or not (in the interoperable way it shouldn't), they're both meant to do the same thing for its own kind, i.e. bring in another WSDL's (in the WSDL case), or another XSD's (in the XSD case) definitions in scope, thus allowing a modular approach to authoring.
The attributes you're referring to are meant to be equivalent, in the same way an import in Java more or less matches a using in C#.
However, the specifics around each are different if you consider the WSDL 1.1 note: while in XSD the schemaLocation attribute is optional for xsd:import (since an import's location may be resolved through its namespace using other means allowed by the spec), the same was not built into the WSDL 1.1 note for the location attribute.
Also, the XSD spec is explicitly allowing for an override:
The ·actual value· of the schemaLocation, if present, gives a **hint** as to where a serialization of a ·schema document·...
If you look for the same in WSDL 2.0, you will notice that now WSDL supports an include in addition to the old import, basically following the same semantics relative to the namespace associated with the directive. More so, the use of the location attribute is also consistent to that in the XSD, which in return should foster a catalog-based approach to resolve the "dangling" imports.
To round it up, given the mandatory location attribute in WSDL 1.1, it didn't make sense to talk about catalogs or overrides since it was not implied or allowed by the note.
Related
Nutshell: The Entity Framework Provider for WCF Data Services pulls the schema namespace and EntityContainer name directly from the namespace and class name of the DbContext, respectively. This is also true for DbContexts that are developed using the code-first method.
Is there a way to modify this provider behavior a posteriori--that is, without modifying the class name or the EDM(X)?
Background/caveats/opinion: This is a handy behavior for prototyping, but in a production scenario, the class name is itself an implementation detail that should be hidden from service consumers.
Further, in my case the name cannot be changed, since I am using a framework that provides a very generic DbContext that I am then composing/extending.
Note that I am not discussing a way to create more "space" between the CLR and EDM representations of the data model. Rather, I'm looking for a way to modify the behavior of the DataService<T> extension itself, so that the internal CLR namespace and DbContext extension class name (preserved in the EDM, which is totally okay) aren't exposed externally.
The specific customization points in the service metadata (custom-ns and custom-container below):
<edmx:Edmx Version="1.0" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx">
<edmx:DataServices m:DataServiceVersion="1.0" m:MaxDataServiceVersion="3.0" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<Schema Namespace="<custom-ns>" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
<EntityType Name="EgEntity">
.
.
.
</EntityType>
.
.
.
<EntityContainer Name="<custom-container>" m:IsDefaultEntityContainer="true">
<EntitySet Name="EgEntity" EntityType="<custom-ns>.EgEntity" />
.
.
.
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>
In code-first, you can specify the schema for tables in the SSDL with the Table annotation (look at the Schema property). Unfortunately, I don't think you can overwrite the schema namespaces used in the CSDL with either attributes or the model builder (please note that I haven't extensively researched this).
You may attempt to play with namespace aliases, although I'm not sure this would work as you intend.
In model-first and database-first, see this question which seems to answer yours. Let me know if it doesn't.
I realize this answer is not too helpful, but I would like to suggest that you specify proper namespaces for your codebase, even (especially) for production. This is because I can't immediately see why a namespace should be "hidden" in any normal scenario, but please do expand on your use-case if you disagree.
That being said, I agree that one should be able to map proper CLR namespaces to different EDM schemas for other reasons, I guess everybody is OK with using the same names as long as they make sense. By the way, don't forget vendor prefixes, especially since you're exposing these names to the network.
Note that the third-party framework namespace shouldn't be relevant as long as the context class is not sealed. Usually, entities are defined as POCOs so that's normally not a problem either. Thus, the standard solution would be to extend this generic context class in a namespace of your own, along with the entities.
My XML files have restrictions on the child elements, but it really doesn't matter what the name of the root element is. How can I incorporate this into my XSD? I've tried using <xs:any> but I get:
"S4s-elt-invalid-content.1: The Content Of 'schema' Is Invalid. Element 'any' Is Invalid, Misplaced, Or Occurs Too Often."
So I tried missing the name off the element tag like this: <xs:element> but then I get:
"S4s-att-must-appear: Attribute 'name' Must Appear In Element 'element'."
Use a named type, and tell your validator to start validation at the root element using that type.
(There is one possible hitch with this: XSD 1.0 suggests that as one possible invocation option, but does not require validators to provide it, so there's no guarantee the validator interface you use will support it. Depends on your validator. Worth trying, at least.)
Another way to put this: you already have what you are asking for, because your XSD schema never cares what the root element of your document instance is called. An XSD schema provides a set of element and type declarations (among other things). A validator can be requested to start the validation at any point in the document, not just the root, and with either an element declaration or a type declaration, or in 'lax wildcard mode' (the most common default). If your validator doesn't offer the invocation options you want, it's a flaw in your choice of validator, not a gap in XSD.
I think I might just make the requirement stricter and insist on using a particular tag as the root element. The fact that the application doesn't care is not really a problem.
It seems (to me) strange that this limitation exists, but I am new to XSDs.
I am currently teaching myself RDFa Core 1.1 after successfully learning RDFa Lite rather easily. Straight to the point, I can't understand two things: the difference between property and rel, and the difference between resource and about.
Please explain to me in simpler terms than the spec :)
property vs. rel:
Both attributes indicate a predicate of a triple, e.g. rel="http://purl.org/dc/terms/creator, which is the predicate ... has as a creator: ....
The difference is, from where they take their object. Slightly simplified, the rules for property are: The object is taken ...
from a valid content attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid resource attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid href attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid src attribute or, if this is not present in the tag,
from the inner content of the element started by the tag.
Slightly simplified, rel differs in two aspects:
It takes its object only from a resource or a href or a src attribute.
It takes its object not only from an attribute of the same tag, but may also take it from descendant tags. The whole mechanism is called "chaining": "This is the main difference between #property and #rel: the latter induces chaining, whereas the former, usually, does not." 1 Usually, but property can induce chaining if used with typeof (cf. 2).
about vs resource:
about is the attribute to indicate the subject of a triple. The rules for resource are more complicated: It may indicate a subject or an object, and chaining plays a role here, too.
IMHO, chaining is the most complicated and confusing part of RDFa (and does not give you more than syntactic sugar). I would avoid chaining. This is possible by avoiding the attributes rel, rev, resource and typeof, which brings some further simplification at the same time. Thus, I use only the following attributes:
about for the subject
property for the predicate
content or href or src (or the inner content of the element) for the object, following the rules outlined above
lang for a language tag for object literals, e.g. lang="en"
datatype for a datatype tag for object literals
prefix (but only once in a document), so that I can abbreviate URLs by prefixing, e.g. property="dc:creator"
vocab (rarely and at the most once in a document), so that I can abbreviate URLs implicitly, e.g. property="creator".
(And I use the tag <base href="..."> to indicate the URL base value of the document.)
This is a strict, safe, easy-to-use and easy-to-parse subset of RDFa and allows to express any triple you want.
I would personally recommend to ignore / avoid using rel and about, they are not really necessary to write RDFa if you follow the rule of thumb that you should not try to be too smart by stuffing as many attributes as possible in a given HTML element. There are around for backward compatibility reasons. The other attributes from 1.1 are worth learning though: content and datatype.
Stephan's advice is in general conformance with RDF Lite 1.1, which does not include #rel or #about for precisely these reasons.
Another good rule of thumb is to not try to include markup of more than one entity on a given element, which was often an example of specifying an images license.
#property and #rel are very similar to each others, but served different purposes in RDFa 1.0, but this was confusing, even for experts. (Formerly, #rel was used for specifying objects which are other nodes, and #property was used for specifying literal values. While there are some remaining differences, but sticking to non-clever markup, you can do everything with #property that you could do with #rel.
Similarly, #about can be avoided to just use #resource. The difference is that #about sets the current subject and #resource the current object, but for child nodes the parent object (taken from the parent's current object becomes the current subject. There were another minor differences concerning the presence of #typeof, but if you only use #resource, it pretty much does what you want.
To summarize the best practices from RDFa Lite 1.1 you can also check out the RDFa 1.1 Primer:
stick to #vocab, #prefix, #property, #resource, and #typeof
avoid making more than one statement in a given element
We use early-bound class for development. But occasionally we use attribute names.
There is a way to do it using reflections, but reflections are not allowed in sandbox plugins.
What are the approaches to getting an attribute from proxy types without relying on reflections?
Opportunity.OpportunityId.AttributeName
You have a couple options:
You can use a RetrieveEntityMetadata to the list of attributes that the entity contains. You won't be able to use any early binding here, but you can inspect the results at run time to see what are valid attributes for the entity.
You could also create a simple utility that uses reflection to auto-generate a class or enum that contains the list of attributes before you actually deploy. Just add the class to your plugin dll and you'd have the benefits of early binding of entity attributes when developing your plugin, without having to do reflection at runtime.
Is it possible to have xsd.exe add "IsNullable=false" to XmlAttributes for fields/properties that are defined in the schema as being required?
Xjc adds it to the Java annotation, but I haven't found a way to get Xsd.exe to do something similar.
I'm trying to use reflection to do a merge of our configuration files that isn't configuration file type dependent. I want to use the required attributes of an element to determine if that element exists in both files or just one.