Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/DID-Data-Object-References.md

@talltree @ken-ebert Although this paper is focused on DID Data Object References, the paper doesn't have a clear, definitive definition (sentence/statement) about what a DID Data Object Reference is.

Consider the following single "Hashlink" example from the paper https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/DID-Content-References.md ...

did:sov:21tDAKCERh95uGgKbJNHYp!hl:zQmWvQxTqbG2Z9HPJgG57jjwR154cKhbtJenbyYTWkjgF3e

1. How is a DID Resolver for the "did:sov:" DID method supposed to know what type of JSON document to return for the identifier 21tDAKCERh95uGgKbJNHYp (within the "did:sov:` DID method context)?

Clearly the data for the object as serialized and stored on the ledger will know its object type (via some sort of type or subtype attribute) ...i.e. whether the corresponding object is a DID Document, a Hashlink object, etc.

2. What if 21tDAKCERh95uGgKbJNHYp is the id for a DID Document and the Resolver is asked to apply the "!" operator to a DID Document instead of an intended Hashlink object? Does the Resolver return some sort of "type mismatch" error diagnostic to the caller?

CC: @talltree @peacekeeper

@talltree In Appendix A of https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/draft-documents/understanding-dids-in-greater-depth.md#appendix-a-anbf-for-dids-and-did-urls , there is some sort of "syntax" tag that is missing from the beginning of the draft ABNF specification (to make it machine processable/validateable). See the first (light gray) line in the following:

; !syntax("abnf")
did                       = "did:" method ":" method-specific-idstring
method                    = 1*methodchar
methodchar                = %x61-7A / DIGIT
method-specific-idstring  = idstring *( ":" idstring )
idstring                  = 1*idchar
idchar                    = ALPHA / DIGIT / "." / "-"
did-url                   = did [ did-relative-ref ]
did-relative-ref          = did-fragment-ref / did-content-ref / did-service-ref
did-fragment-ref          = "#" fragment
did-content-ref           = "!" content-id                                                  
content-id                = content-idstring *( ":" content-idstring )                      
content-idstring          = 1*uri-safe-char                                                 
uri-safe-char             = idchar / "_" / pct-encoded
did-service-ref           = "$" service-id [ path-abempty ] [ "?" query ] [ "#" fragment ]
service-id                = service-idstring *( ":" service-idstring )
service-idstring          = 1*uri-safe-char
did-reference             = did-url / did-relative-ref

Here's an example: http://arran.fi.muni.cz/bnfparser2/share/rfc4234-B.1.abnf

Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/DID-Data-Object-References.md

@talltree @ken-ebert I believe the proposed additions to the proposed ABNF (i.e. the "!" and "$" operators) are superfluous.

The current proposed ABNF specification (listed in the paper) already includes the "#" operator for deferencing any component of a DID Document that has a "#" anchor in it's id attribute. See use case 2a in w3c-ccg/did-resolution#32 for an example as well as Example D in w3c-ccg/did-spec#170 (comment)

This might similarly lead us to question why is the ";" operator is needed if we have the "#" operator? I think having both makes sense because the ";" operator can have a very different semantic meaning: see use cases 2b, 2c and 2d in w3c-ccg/did-resolution#32

Conclusion: This paper doesn't establish a strong rationale for adding "!" and "$" as new operators in DID ABNF grammar ...(apologies for sounded so brutal) but they appear to be "syntactic sugar" with no additional semantic value above what the "#" operator already provides.

As I state at the bottom of w3c-ccg/did-resolution#32 (comment),

The DID ABNF is more than a syntax specification ...more than a grammar...

The DID ABNF is an algebra for working with the DID Document associated with a DID.

Let's use it that way. We don't need to invent anything new or extra.

That is, we only need one "+" sign in our algebra (figuratively speaking) (aka "#" operator), not 3 IMO. Just like "+" is overloaded for integers, real numbers, strings, etc. in ordinary algebra/arithmetic, the "#" operator can similarly be applied to any component of a DID Document that has an id attribute containing a "#" anchor.

Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/DID-Data-Object-References.md

@talltree @ken-ebert "naked DID" is a non-technical term that is not defined in the paper.

Is a "naked DID" simply a did as defined in the proposed ABNF grammar? If so, then I suggest using the term did ...and avoid using/inventing a new, non-technical term.

Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/did-namespace-records.md

@talltree For example, it is already permissible for a DID method to define second, third, etc. level of ":" separated names as part of the method-specific-idstring as described the latest proposed DID Base ABNF Syntax.

e.g. did:xyz:testnet:1234abcd

This paper should be updated to document and acknowledge this current state capability.

Is this intent of this paper to propose a universal solution across all DID methods?

Issues

1. I believe there is a strong probability that the proposed concepts of DID namespaces will create confudsion with the current state DID method concept.

2. For each level, it will be necessary to state which DID Resolver is to be used to resolve which proposed DID namespace? There is an existing proposal for querying the ("first level") methods within a particular DID Resolver - see use cases 6, 7, 8 in w3c-ccg/did-resolution#32. In addition, use case 10 can be used to query second, third, etc. level names within a DID method within the scope of a particular DID resolver.

3. Is this proposal necessary? ...or can this be requirement be "resolved" by clarifying the existing DID resolution use cases? That is, is:
   a) new, more complex DID Document construct needed? or...
   b) can be addressed using a capability within DID Resolution?
   I believe it can be addressed using the latter.

I believe we should strive to keep the DID Document algebra as concise as possible.

Reference: email from the maintainers of bnfparser2...

From: Václav Vacek [email protected]
Sent: March 7, 2019 10:24 AM
To: Michael Herman (Parallelspace) [email protected]
Cc: Vojtech Rehak [email protected]; [email protected]
Subject: Re: FW: http://arran.fi.muni.cz/bnfparser2/ is failing with a web server error

Hi Michael,
please let me take over from Vojtěch - I am the author of the Bachelor thesis on the parser.

I could not reproduce the error with (probably) the same input as you but found the problem anyway - your grammar is missing the ABNF core rules (ALPHA, DIGIT in this case). Having copied these rules to your grammar, I could successfully parse the string:
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9

(As a side note, one should be able to link the core rules in the GUI - it is the last checkbox above the file upload - but it seems not to work properly. I hope the workaround is not too messy. :-) The corrected/augmented grammar file is attached.

As a bonus, I have a secret tip. Technically, it is documented somewhere in the thesis BUT...

If you put a "@" behind a nonterminal on the right side of a rule, the substrings generated by this nonterminal will be marked in the output:
did = "did:" method@ ":" method-specific-idstring

Hope this helps! And thanks for trying the parser!

Best regards
Václav Vacek

We will be promoting the advance topic readings to attract our remaining set of attendees, and this year we are trying to organize them a bit better to allow newcomers to know a bit more about what each is about.

Could you please read and update the abstract and #hashtags we initially created for your paper at https://github.com/WebOfTrustInfo/rwot8-barcelona/README.md

In addition, if you feel your paper belongs in a different major category, or needs a new category, please feel free to change it.

I have set up everyone who submitted topic papers as a collaborator for this repo, which means you can use the web interface to edit the /README.md file. To prevent PR conflicts, it may be easier to accept your collaborator status, edit quickly and submit your changes directly, rather than do a PR.

If you can do this by Wednesday it would be appreciated, as we are sending another mailing out soon and some promotions on social networks.

@alexpuig, @sandhawke, @rhiaro, @AlbertoElias, @dmitrizagidulin, @satazor, @stonematt, @ferranrego, @keutmann, @RieksJ, @brentzundel, @airoak, @shigeya, @burnburn, @cstoecker, @hackylawyER, @dlamers, @awoie, @creatornader, @sheldrake, @wip-abramson, @talltree, @Drabiv, @nalamillo, @benjibeta, @joaosantos15, @karolinkas, @mavarley, @ameba23, @msporny, @davidastark, @bford, @peacekeeper, @agropper, @andrewhughes3000, @luca-boldrin, @bumblefudge

Thanks!

Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/Universal-DID-Operations.md

@peacekeeper I've documented several DID resolution use cases (and their proposed HTTP bindings) here: w3c-ccg/did-resolution#32

Issues

1. To be complete, I recommend that your paper also highlight the current state with respect to DID Document resolution and dereferencing because there represent good patterns for the additional capabilities you are proposing.
2. Although your proposal make sense for a programmatic API, I feel strongly that the proposed HTTP bindings are much more complex that they need to be or should be.
   I believe we should strive to keep the DID Document algebra as concise as possible.
3. For example, the method and options parameters for the create() method should be simply encoded into a single did parameter IMO. Let's not create additional, more complex syntax where it is not necessary. See w3c-ccg/did-resolution#32 (comment)

Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/Using-Immutable-Data-Objects.md#mapping

@ken-ebert Is it possible to use the concept of Overlays to support Mappings as well as some of the other concepts you discuss in this paper? ...e.g. for example, by adding a Mapping card to the Overlay card stack?

Reference: Appendix F - Indy Overlays Architecture Reference Model (OVERLAYS ARM)

@talltree What is the justification for the new

1. "$" operator?
2. "!" operator?

"$" is particularly problematic because "$" is already in common usage in many accepted international specifications for URLs:

• OASIS/ISO OData System Query Options: http://docs.oasis-open.org/odata/odata/v4.01/cs01/part2-url-conventions/odata-v4.01-cs01-part2-url-conventions.html#_Toc505773217

Reference:

• w3c-ccg/did-resolution#32