Is it correct to say that http:// or mailto: are a namespace in RDF?
Where can I find a definition what a namespace is? An can I say that a namspace is a URI?
RDF itself has no notion of namespaces. However several RDF serialization formats (like RDF/XML and Turtle) use namespaces to abbreviate URIs such as by using CURIEs. The CURIE spec mandates the prefix to be mapped to an IRI, so you couldn't map it to just "http://".
Found the solution by myself. Here is the answer:
A uri consists of the following format:
URI = scheme:[//authority]path[?query][#fragment]
A URI must contain a scheme and a path. http and mailto are only schemes and not considered as a URI because the path is missing.
A namespace is definied by a uri. However, http:// and mailto: is not a URI and that is why they are not a namespace.
Related
Is it better to have a xmlns URI with https protocol?
For example this is the recommended way by the manual:
<http xmlns="http://www.springframework.org/schema/security"/>
Is it legal and better to use this way?
<http xmlns="https://www.springframework.org/schema/security"/>
Are there XML parsers that try to connect to an address defined by xmlns URI?
Parsers always download schemas by xsi:schemaLocation attribute?
The URI is the namespace name, which identifies the namespace.
While, in case of some URI schemes (like http, https, ftp etc.), it would be possible to provide the schema (or other related information), this is "not a goal":
It is not a goal that it be directly usable for retrieval of a schema (if any exists).
(Most URI schemes wouldn’t allow this to begin with, e.g., urn, tag, jabber etc.)
You should specify the URI exactly as documented, as this is what consumers expect and look for (most consumers probably never try to actually retrieve the URI), and XML Names 1.0 is pretty strict about comparing URIs.
All these would be different namespace names, even if they would resolve to the same Web document:
http://www.springframework.org/schema/security
http://www.Springframework.org/schema/security
httP://www.springframework.org/schema/security
http://www.springframework.org/schema/Security
https://www.springframework.org/schema/security
https://www.springframework.ORG/schema/security
In any xml file i can say what namespace I refer to using xmlns-attributes to describe the namespace. It is well descibed here: What does "xmlns" in XML mean?
Then I can use a xml schema having a target namespace so that everyone knows that the schema describes that namespace. One question about that is found here: Why do we need targetNamespace?
Using json-schema we can define schemas for json documents. My mental model is that this is roughly equivalent to having a xsd file.
Now, how do I reference the schema in a json object? I can reference a schema using $schema attribute, but how do I declare the name of the schema i develop myself? I dont understand the equivalent of targetNamespace
Researching for writing the question I found the answer. The closest thing of a targetNamespace is the $id attribute. The standard states...
The "$id" keyword defines a URI for the schema, and the base URI that
other URI references within the schema are resolved against. A
subschema's "$id" is resolved against the base URI of its parent
schema. If no parent sets an explicit base with "$id", the base URI is
that of the entire document, as determined per RFC 3986 section 5
[RFC3986].
... which is kind of the mirror image of the leading text for $schema...
The "$schema" keyword is both used as a JSON Schema version identifier
and the location of a resource which is itself a JSON Schema, which
describes any schema written for this particular version. The value
of this keyword MUST be a URI [RFC3986] (containing a scheme) and this
URI MUST be normalized. The current schema MUST be valid against the
meta-schema identified by this URI.
so it is essentially the same thing.
Some things to note, however:
a) you use $schema in a schema to define what schema should be used for defining your own custom schema. It is not stated in the spec that $schema in any kind of object should indicate validation for a schema.
b) You may define in your schema that $schema should be an indication about what schema to use for validation.
c) there are other ways to indicate the schema for data. One such example is using content-type in http headers. Another is to use link http headers.
d) vscode and visual studio both interpret $schema as a reference to a schema for use in validation
The issue has been discussed at the github repo for the spec.
https://github.com/json-schema/json-schema/issues/235
https://github.com/json-schema/json-schema/issues/220#issuecomment-209452992
Is it possible to use invalid(non existing) Uri for JSON schema definition?
So that I can specify it and use for versioning, without need to deploy it anywhere?
A URL is expected to resolve to the resource, so if you say "this is the URL for the schema" then that URL should resolve to the schema.
However, URLs are not the only sort of URI - it sounds like a URN might be what you want. In contrast to a URL (uniform resource location), a URN (uniform resource name) is an identifier for a resource, but it doesn't carry a generic method to resolve it.
For example, the URN urn:ietf:rfc:2648 is an identifier for RFC 2648, but there isn't a standard way to get the RFC text from just that URN (you'd need some kind of special service that knew about urn:ietf:rfc:... URNs). If you used something like this, then it should (in theory) do what you want.
(You might run into trouble referencing one schema from another if your library is mistakenly assuming all URIs are URLs, but that would be a bug in your library.)
As with any user supplied data, the URLs will need to be escaped and filtered appropriately to avoid all sorts of exploits. I want to be able to
Put user supplied URLs in href attributes. (Bonus points if I don't get screwed if I forget to write the quotes)
...
Forbid malicious URLs such as javascript: stuff or links to evil domain names.
Allow some leeway for the users. I don't want to raise an error just because they forgot to add an http:// or something like that.
Unfortunately, I can't find any "canonical" solution to this sort of problem. The only thing I could find as inspiration is the encodeURI function from Javascript but that doesn't help with my second point since it just does a simple URL parameter encoding but leaving alone special characters such as : and /.
OWASP provides a list of regular expressions for validating user input, one of which is used for validating URLs. This is as close as you're going to get to a language-neutral, canonical solution.
More likely you'll rely on the URL parsing library of the programming language in use. Or, use a URL parsing regex.
The workflow would be something like:
Verify the supplied string is a well-formed URL.
Provide a default protocol such as http: when no protocol is specified.
Maintain a whitelist of acceptable protocols (http:, https:, ftp:, mailto:, etc.)
The whitelist will be application-specific. For an address-book app the mailto: protocol would be indispensable. It's hard to imagine a use case for the javascript: and data: protocols.
Enforce a maximum URL length - ensures cross-browser URLs and prevents attackers from polluting the page with megabyte-length strings. With any luck your URL-parsing library will do this for you.
Encode a URL string for the usage context. (Escaped for HTML output, escaped for use in an SQL query, etc.).
Forbid malicious URLs such as javascript: stuff or links or evil domain names.
You can utilize the Google Safe Browsing API to check a domain for spyware, spam or other "evilness".
For the first point, regular attribute encoding works just fine. (escape characters into HTML entities. escaping quotes, the ampersand and brackets is OK if attributes are guaranteed to be quotes. Escaping other alphanumeric characters will make the attribute safe if its accidentally unquoted.
The second point is vague and depends on what you want to do. Just remember to use a whitelist approach instead of a blacklist one its possible to use html entity encoding and other tricks to get around most simple blacklists.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the difference between a URI and a URL?
How are URI and URL distinguished?
A URL is a type of URI.
Having said that, most people use the two terms interchangeably.
From wikipedia (URL):
In computing, a Uniform Resource Locator (URL) is a Uniform Resource Identifier (URI) that specifies where an identified resource is available and the mechanism for retrieving it.
So, a URI identifies a resource (acts as its ID), a URL specifies the resource location.
URI - Uniform Resource Identifier
URL - Uniform Resource Locator
A URI identifies a resource by meta-information of any kind.
A URL locates a resource on the net, which means if you have
a URL and the appropriate protocol you can retrieve the resource.
One characteristic of a URI is, that it gives information about
exactly one resource. Another is there can be more than one URI
describing the same resource.
From RFC 2396 here, I quote
A URI can be further classified as a locator, a name, or both.
The term "Uniform Resource Locator" (URL) refers to the subset of URI
that identify resources via a representation of their primary access
mechanism (e.g., their network "location"), rather than identifying
the resource by name or by some other attribute(s) of that resource.
The term "Uniform Resource Name" (URN) refers to the subset of URI
that are required to remain globally unique and persistent even when
the resource ceases to exist or becomes unavailable.
As Oded says, URL is a type of URI.
A quick google turns up the following complete answer:
http://www.bernzilla.com/item.php?id=100