Re: Introducing TreeLDR

It would be useful to me to hear a comparison and contrast against other extant langs that (maybe) could be used for this, eg

Always wondering which use case any given prior art could not fulfill. There probably are some, and IMO it’s a gift to posterity to document that. It’s also good marketing about the unique value proposition, if any, about the new thing.

Thanks for making this and sharing it Wayne.

Sent from my iPhone

> On Aug 27, 2022, at 7:12 AM, Manu Sporny <> wrote:
> On Fri, Aug 26, 2022 at 1:13 PM Wayne Chang <> wrote:
>> At this stage, we're pre-official release and are looking for feedback to see if it would save anyone else effort
> Hey Wayne and Timothée, TreeLDR is *really cool*... more below.
>> Hi all, we wrote about our tool called TreeLDR
> Alright, first up, your organization's ability to have catchy names
> for software projects continues to impress. TLDR (Too Long, Didn't
> Read) sums up what we've found most developer's feelings toward the
> JSON-LD/JSON Schema/Verifiable Credentials/DIDs stack... "I just can't
> be bothered to read all of this... the customer wants it NOW! Just
> give me some good tooling so I don't need to learn the equivalent of
> x86 Assembly for Verifiable Credentials"!
>> makes it easier for developers to work with JSON Schema, JSON-LD, and a variety of other data schema-related languages you need to consider when working with digital credentialing systems.
> A couple of random thoughts after reading through the blog post:
> * I wonder if we can use TreeLDR to generate the base JSON Schema for
> VCs and VPs in the VCWG. It feels like that would be proof that
> TreeLDR could represent just about any other type of VC one could
> dream up. I know Orie has done work in this space as well; I don't know
> how much overlap there is there?
> * A TreeLDR playground might be useful, just as a syntax checker/live
> editor, etc.
> * We've experienced that some people have a religious hatred for
> namespaces, and others don't... the first population tends to be VERY
> noisy when they complain, and tend to derail important conversations
> around the real benefits of such an approach. More on this below:
> During the development of JSON-LD (~2008 timeframe), we introduced the
> concept of CURIEs (Compact URI Expressions)... which was something
> that existed in XML and XHTML2, which enable you to define a namespace
> and alias it, and then use it in other expressions. For example:
> vc:credentialSubject
> Using namespaces exposes you to a group of developers from the late
> 90s and early 2000s that continue to carry trauma from that time
> related to "how difficult namespaces were to manage". That vocal
> minority will fight you every step of the way and tends to derail many
> conversations. This is why many of the JSON-LD examples these days,
> and newer contexts don't use CURIEs at all:
> Now, I personally don't have any issue with the use of CURIEs or
> namespaces... all modern programming languages utilize namespaces to
> manage subsystem complexity. That said, these "XML namespace haters"
> can create great friction when it comes time for moving these sorts of
> things through large enterprises, with Enterprise architects from the
> late 90s, that have decided that XML namespaces (and colons) are the
> devil.
> All that to say, try to consider ways of eliminating or hiding the use
> of namespaces. For example, instead of "vc:credentialSubject",
> consider "vc.credentialSubject". Yes, absolutely ridiculous, changing
> ":" to "." -- they're the same thing... but for some reason, people
> don't respond as negatively to namespace dot-notation as they do to
> namespace colon-notation. Apes are funny that way.
> Just some off-the-cuff remarks, hope they're helpful.
> Finally, thank you for investing Spruce's resources on new
> technologies and community tooling. It creates a rising tide that
> lifts us all.
> -- manu
> -- 
> Manu Sporny -
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)

Received on Saturday, 27 August 2022 15:01:21 UTC