I have a class in my sourcecode:
public class TypeUserdef : SymbolType
which is a DTO for XML Serialization, now the code analysis reports a warning:
MSBUILD : warning CA1704: Microsoft.Naming : Correct the spelling of 'Userdef'
in type name 'TypeUserdef'.
I put the entry into the user dictionary (a customer dictionary in my project set to buildAction = "CodeAnalysisDictionary"):
<Dictionary>
<Words>
<Recognized>
<word>userdef</word>
</Recognized>
</Words>
</Dictionary>
Now the funny thing is the dictionary works very well for a lot terms. Just the term "userdef" and "vars" report errors. (Even spelling errors in the same code file can be ignored). What is so special about those terms above?
I found the Problem, while i know that xml is case sensitive it is quite difficult to spot that some entries in a few hundred lines of xml are lower cased...
<Word></Word> works as expected.
Related
I'm using Ruby scripts to to round-trip a SKOS vocabulary definition in Turtle format through to a spreadsheet (via CSV) and back to allow non-technical people to check and update the localised phrases. This then needs to be converted back into the Turtle format with as little non-significant churn and variation from the original as possible.
The spreadsheet has these columns (for the sake of this example):
vocab ID
term ID
property ID
value
EN
FR
...
vocab ID contains an abbreviated URI for the vocabulary, e.g. foo:bar.
property ID contains abbreviated URIs identifying a property of either the vocabulary itself or a term in it. (such as dcterm:created or dc:title for the former case; or skos:prefName or skos:altLabel for the latter). A special case of the former is base_uri, defining the vocab's base URI.
term ID contains IDs identifying a term in the vocabulary when appropriate - or it is blank for properties of the vocabulary itself.
value is an unlocalised string literal, or some other sort of literal (like a date), or an URI, as appropriate. It may be blank if the value is a localised string - the other columns then contain the translated versions of the property in various languages. The column name is the two-letter identifier for the language.
Creating the CSV is not the problem - what is a little tricky is reading back the literal values and recreating the correct literal values.
Here's the thing: I'd like to be able to infer the XSD datatype of the property from the RDF::Term for it. I can look the latter up from the abbreviated URI, using RDF::Vocab. However there seems to be no mapping I can find in these libraries to the XSD datatype (whether mandatory or merely suggested.)
This seems to mean I must create a mapping from property IDs to the XSD datatype myself if I'm to avoid ending up with all the values becoming string literals by default (which wouldn't preserve the original datatypes).
Can anyone advise if I'm correct here, or is there a way to infer the nominal XSD datatype to use using the Ruby RDF libraries?
I presume you mean an RDF::Vocabulary::Term instance, which typically is an IRI, but contains accessors for a related vocabulary definition.
The Documentation for RDF::Vocabulary::Term describes the generic accessors you can use, and for a term based on a property, you might look at either range or rangeIncludes accessors to get an idea of what the preferred values that might be used as the object of a triple using this term.
The built-in vocabularies are minimal, pretty much limited to RDF, RDFS, XSD, and OWL. Load the rdf-vocab gem, and many other vocabularies are loaded. You can also use the RDF::Vocabulary.from_graph class method to instantiate a new vocabulary, including its term definitions, from a graph.
For example, see the following:
require 'rdf/vocab'
RDF::Vocab::SCHEMA.name.rangeIncludes # => [RDF::Vocab::SCHEMA.Text]
RDF::Vocab::FOAF.name.range # => [RDF::RDFS.Literal]
Other common accessors correspond to basic RDFS, OWL, SKOS, and schema.org annotation properties. Or, you can access an arbitrary annotation property using #attribute_value and #properties accessors.
In some cases, property range may be more complex, take for example, the term definition for skos:member:
property :member,
definition: "Relates a collection to one of its members.".freeze,
domain: "http://www.w3.org/2004/02/skos/core#Collection".freeze,
isDefinedBy: "http://www.w3.org/2004/02/skos/core".freeze,
label: "has member".freeze,
range: term(
type: "http://www.w3.org/2002/07/owl#Class".freeze,
unionOf: list("http://www.w3.org/2004/02/skos/core#Concept".freeze, "http://www.w3.org/2004/02/skos/core#Collection".freeze)
),
type: ["http://www.w3.org/1999/02/22-rdf-syntax-ns#Property".freeze, "http://www.w3.org/2002/07/owl#ObjectProperty".freeze]
Additionally, the rdf-reasoner gem can form entailments over vocabularies to provide additional domain and range (and other) information based on subProperty hierarchies (as well as class hierarchies for rdf:type).
One of my classes has a public property named Ttl. This is supposed to follow the CA1709 rules:
By convention, two-letter acronyms use all uppercase letters, and
acronyms of three or more characters use Pascal casing. The following
examples use this naming convention: 'DB', 'CR', 'Cpa', and 'Ecma'.
The following examples violate the convention: 'Io', 'XML', and 'DoD',
and for nonparameter names, 'xp' and 'cpl'.
Now, code analysis complains about my property, telling me it violates CA1704 (bad spelling).
I tried adding it to my CustomDictionary.xml like this:
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="CodeAnalysisDictionary.xsd">
<!-- Some unimportant elements are here in the real file -->
<Acronyms>
<CasingExceptions>
<Acronym>Ttl</Acronym> <!--Time To Live-->
</CasingExceptions>
</Acronyms>
</Dictionary>
I tried putting lower, upper and camel case into the dictionary, but none of them will remove the spelling complaint. Is there a way to add this acronym to the XML or do I just have to suppress the message for my properly named property?
You added "Ttl" as a casing exception. In fact it's not. It's three letters in Pascal case.
What you did not do is add "Ttl" as a word.
<Words>
<Recognized>
<Word>Ttl</Word>
Make sure you need it at all. Most .NET languages have "no abbreviations" as a good naming convention.
Could you please help me on this xpath expression evaluation
I am working on fetching the proxy references. In the xml file the references will get stored as:
One way of XML file will have the reference as below:
con1:service ref="MyProject/ProxyServices/service1"
xsi:type="con2:PipelineRef" xmlns:ref="http://www.bea.com/wli/sb/reference"/
here in the xml file the name spaces are:
xmlns:con1="http://www.bea.com/wli/sb/stages/config"
xmlns:con2="http://www.bea.com/wli/sb/pipeline/config"
Another way of XML will have the reference as below.
con1:service ref="MyProject/ProxyServices/service2"
xsi:type="ref:ProxyRef" xmlns:ref="http://www.bea.com/wli/sb/reference"/
here in the xml file the name spaces are:
xmlns:con1="http://www.bea.com/wli/sb/stages/config"
xmlns:ref="http://www.bea.com/wli/sb/reference"
I have used this xpath expression, this is not fetching the reference service values, could you please help what is wrong in it.
"//service[#type= #*[local-name() ='ProxyRef' or #type=#*[local-name() ='PipelineRef']]/#ref"
when I used like this it is working but, name space prefix is keep on changes when there are multiple references in the xml file.
"//service[#type='ref:ProxyRef'or #type='con:PipelineRef' or #type='con1:PipelineRef' or #type='con2:PipelineRef' or #type='con3:PipelineRef' ...#type='con20:PipelineRef' ]/#ref";
Now here basically the type attribute PipelineRef is keep on changing the name space prefix from con to con(n). Now I am looking for something which supports some thing like #type='*:PipelineRef' or #type='con*:PipelineRef' or the best way to fetch the service element reference attribute value.
Thanks in advance.
Try using contains() like so :
//service[contains(#type,':ProxyRef') or contains(#type,':PipelineRef')]
Another alternative would be using ends-with() function which is more precise for this purpose compared to contains() function. However, ends-with() isn't available in xpath 1.0, so there is a chance that you need to implement it yourself (feasible, but the xpath result is less intuitive for me).
Given the following ruby code :
require 'nokogiri'
xml = "<?xml version='1.0' encoding='UTF-8'?>
<ProgramList xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns='http://publisher.webservices.affili.net/'>
<TotalRecords>145</TotalRecords>
<Programs>
<ProgramSummary>
<ProgramID>6540</ProgramID>
<Title>Matalan</Title>
<Limitations>A bit of text
</Limitations>
<URL>http://www.matalan.co.uk</URL>
<ScreenshotURL>http://www.matalan.co.uk/</ScreenshotURL>
<LaunchDate>2009-11-02T00:00:00</LaunchDate>
<Status>1</Status>
</ProgramSummary>
<ProgramSummary>
<ProgramID>11787</ProgramID>
<Title>Club 18-30</Title>
<Limitations/>
<URL>http://www.club18-30.com/</URL>
<ScreenshotURL>http://www.club18-30.com</ScreenshotURL>
<LaunchDate>2013-05-16T00:00:00</LaunchDate>
<Status>1</Status>
</ProgramSummary>
</Programs>
</ProgramList>"
doc = Nokogiri::XML(xml)
p doc.xpath("//Programs")
gives :
=> []
Not what is expected.
On further investigation if I remove xmlns='http://publisher.webservices.affili.net/' from the initial <ProgramList> tag I get the expected output.
Indeed if I change xmlns='http://publisher.webservices.affili.net/' to xmlns:anything='http://publisher.webservices.affili.net/' I get the expected output.
So my question is what is going on here? Is this malformed XML? And what is the best strategy for dealing with it?
While it's hardcoded in this example the XML is (will be) coming from a web service.
Update
I realise I can use the remove_namespaces! method but the Nokogiri docs do say that it's "...probably is not a good thing in general" to do this. Also I'm interested in why it's happening and what the 'correct' XML should be.
The xmlns='http://publisher.webservices.affili.net/' indicates the default namespace for all elements under the one where it appears (including the element itself). That means that all elements that don’t otherwise have an explicit namespace fall under this namespace.
XPath queries don’t have default namespaces (at least in XPath 1.0), so any name that appears in one without a prefix refers to that element in no namespace.
In your code, you want to find Program elements in the http://publisher.webservices.affili.net/ namespace (since that is the default namespace), but are looking (in your XPath query) for Program elements in no namespace.
To explicitly specify the namespace in the query, you can do something like this:
doc.xpath("//pub:Programs", "pub" => "http://publisher.webservices.affili.net/")
Nokogiri makes this a little easier for namespaces declared on the root element (as in this case), declaring them for you with the same prefix. It will also declare the default namespace using the xmlns prefix, so you can also do:
doc.xpath("//xmlns:Programs")
which will give you the same result.
I need to select some nodes from an XML file (AppNamespace.xaml from a Silverlight XAP file, not that it matters), but the file has namespace stuff so XPath doesn't work. I could waste most of a day trial-and-erroring the bondage-and-discipline nightmare of XmlNamespaceManager and end up with hopelessly fragile code that can't tolerate the slightest variation in the input file (not a great idea in production code), or I could use the ludicrous local-name() syntax[1].
But it would be more convenient to use XPath as a human-readable query language that can be used to return specified nodes or attribute values from arbitrary XML files.
So is there any way to strip the line-noise out of the file? Or am I stuck? Is the labyrinthine imbecility of Linq-to-XML truly the lesser evil?
[1]
//*[local-name() = 'Deployment']/*[local-name() = 'Deployment.Parts']/*[local-name() = 'AssemblyPart']/#*[local-name()='Name']
Update
Five years down the road, I stand behind the term "labyrinthine imbecility" with every fiber of my being, except for a few fibers that want to use something much stronger.
Ed, here's an example of using namespaces with the System.Xml.XPath Extensions class. I've modified it to match the input you're looking at:
string markup = #"
<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" ...>
<Deployment.Parts>
<AssemblyPart x:Name="xamlName" Source="assembly" />
</Deployment.Parts>
</Deployment>
";
XmlReader reader = XmlReader.Create(new StringReader(markup));
XElement root = XElement.Load(reader);
XmlNameTable nameTable = reader.NameTable;
XmlNamespaceManager namespaceManager = new XmlNamespaceManager(nameTable);
nsm.AddNamespace("x", "http://schemas.microsoft.com/winfx/2006/xaml");
nsm.AddNamespace("dep", "http://schemas.microsoft.com/client/2007/deployment");
IEnumerable<XElement> elements =
root.XPathSelectElements("//dep:Deployment/dep:Deployment.Parts/dep:AssemblyPart/#x:Name", nsm);
foreach (XElement el in elements)
Console.WriteLine(el);
Not very complicated. Obviously you already know about XmlNamespaceManager, but I think you got a worse impression of it than it deserves.
When you say "hopelessly fragile code that can't tolerate the slightest variation in the input file", are you blaming namespaces in general, or XmlNamespaceManager? I don't see how either one makes it fragile... any more so than XML processing code without namespaces will not tolerate certain changes in the input document, but will tolerate others.
Have a little respect for other intelligent people in the industry, take a little time to understand the advantages behind a design before you dismiss it, and you will usually find that there are good reasons for what was done.
Not that XML namespaces couldn't be improved upon. However nobody has managed to produce a better standard and get it accepted by the community.
In XPath 2.0 you can use namespace wildcards (if you know what you are doing):
//*:Deployment/*:Deployment.Parts/*:AssemblyPart/#Name
btw. If an attribute doesn't have a prefix it is in no namespace at all. As this is most often the case, I guess, you don't need local-name() for the attribute.
I came here as a result of this search:
and I am adding an "Answer" to cheer on your "5 years on" update.
I was motivated to do this because I have an XML document that uses a tonne of namespaces -
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:x2="urn:schemas-microsoft-com:office:excel2" version="1.0" exclude-result-prefixes="msxsl">
and APPARENTLY I have to know what all those namespaces are in advance in order to hard code the XmlNamespaceManager, or write some code that parses the namespace declarations and adds the relevant name spaces myself. Why in the name of all that is holy does the XmlDocument not manage to do that all by itself?
XmlDocument databaseXml = new XmlDocument();
databaseXml.LoadXml(xslt.XslTransform);
var dbnsmgr = new XmlNamespaceManager(databaseXml.NameTable);
dbnsmgr.AddNamespace("xsl", "http://www.w3.org/1999/XSL/Transform");
dbnsmgr.AddNamespace("ss", "urn:schemas-microsoft-com:office:spreadsheet");
XmlElement databaseStylesElement = (XmlElement)database
Xml.DocumentElement.SelectSingleNode("/xsl:stylesheet/xsl:template");