shexSpec / shex

ShEx language issues, including new features for e.g. ShEx2.1
25 stars 8 forks source link

url-able ShExErrorCode #59

Open ericprud opened 7 years ago

ericprud commented 7 years ago

The whitespace in ShExErrorCode makes the natural URL form require some transformation or encoding. Encoding would look like http://www.w3.org/ns/shex#invalid%20schema.

- enum ShExErrorCode {
-     "invalid schema",
-     "non-conforming graph",
-     "syntax error"
- };
+ enum ShExErrorCode {
+     "invalidSchema",
+     "non-conformingGraph", # or nonConformingGraph
+     "syntaxError"
+ };
gkellogg commented 7 years ago

The Promises Guide says to use the ECMAScript Error type (or DOMException), where the code is a string passed to the error, such as:

const oldPromise = windowA.Promise;
windowA.Promise = () => throw new Error("I break developer code, but not platform code!");

Not really necessary to make these URL-friendly. Of course, in the spec, there are URLs defined for each error for reference purpose, such as that for invalid schema.

ericprud commented 7 years ago

In principle, a ShExErrorCode like "invalid schema" could be identified by http://www.w3.org/ns/shex#12345. It's a little easier on (English-speaking) people who are reading the error code directly (vs. having some interface sanitizing/localizing/contextualizing the results) if the text is property English strings. OTOH, it's easier on parsers (and adds some future-proofing) if there's a procedural mapping from error code to a URL.

Is this list considered extensible? May an implementation add error codes, e.g, "service not available", "query endpoint unreachable", "401 auth required"? Of should they use one of our error codes and stick their details in a new attribute?