proving that conneg is a breaking change

There are two Webid Specs, WebID 1.0 and WebID 2.0.
WebID 1.0 mandates a serialization, say Turtle.
WebID 2.0 mandates conneg, with Turlte and JSON-LD
Alice has a WebID alice.ttl which has been her webid for 10 years.  She uses it with all her solid Apps.
One day Apps switch to WebID 2.0 and the newer JSON-LD becomes the preferred serialization
Alice's WebID is now broken.  Furthermore it's hosted on her own home page using Apache, and she has no ability to fix her webid.  This breaking change, makes all of Alice's work over the last 10 years potentially broken.
QED

Really, @melvincarvalho? This is not an issue. @jacoscaz, I suggest moving this to Discussions, which we specifically opened for things like this.
I also think that we already had this discussion good and well in issue #3 regarding the serialisation formats. Before repeating ourselves here, I would thus suggest you (re)read the past months of that issue. In particular, I explained at length during multiple comments (here, here, here, here and here), why switching to Turtle+JSON-LD using conneg would not break anything the WebID spec aims to support. In an effort to be constructive, I will try my best to summarize those points here as clear and succinct as I can (parts of the following text is copied from my aforementioned comments).

The vast majority of WebID users will be non-technical people, managing their WebID through the GUIs of WebID providers. This includes Alice and Bob, our main fictitious users.

All existing WebID providers (Inrupt, Use.ID, OpenLink, solidweb.me, redpencil.io, inrupt.net, solidcommunity.net ...) already provide Turtle+JSON-LD through conneg. (If I missed some, please tell me.) This is no wonder, because conneg is part of all major web frameworks, and no work at all to add to a server.

Given the above two points, conneg does not break anything for the vast majority of WebID users, and is thus perfectly in line with the main targets for a successful WebID ecosystem.

Now, if you really want to be nitpicky, there are indeed a few people who currently host a static WebID Document. They do so simply because they can: it has up till now been the simplest way to host a WebID. However, people that are skilled enough to host a WebID Document themselves are easily skilled enough to set up conneg over it. I've timed it: it takes about 5 minutes using a free CloudFlare account. I can guarantee you that the majority of these people will do so the instant we add conneg to the spec. Most importantly, however, these these people are not the main target for the spec. They are not the ones for which applications will be built and an ecosystem will grow; they are not the ones to which we must cater.

Thanks for this, replies inline.  I dont think discussions are universally liked, so perhaps lets keep it as an issue, for a bit:

The vast majority of WebID users will be non-technical people, managing their WebID through the GUIs of WebID providers. This includes Alice and Bob, our main fictitious users.

Doesnt really speak to breaking change

All existing WebID providers (Inrupt, Use.ID, OpenLink, solidweb.me, redpencil.io, inrupt.net, solidcommunity.net ...) already provide Turtle+JSON-LD through conneg. (If I missed some, please tell me.) This is no wonder, because conneg is part of all major web frameworks, and no work at all to add to a server.

Not the example I gave of alice.ttl -- there's more than one such webid around.  So this is not a disproof
We dont even have a way to test that conneg works on the servers above.  Trust me, I've spent hours trying to design such a test with the "solid team".  They dont even understand conneg.

Given the above two points, conneg does not break anything for the vast majority of WebID users, and is thus perfectly in line with the main targets for a successful WebID ecosystem.

Again, the proof stands.

Now, if you really want to be nitpicky, there are indeed a few people who currently host a static WebID Document. They do so simply because they can: it has up till now been the simplest way to host a WebID. However, people that are skilled enough to host a WebID Document themselves are easily skilled enough to set up conneg over it. I've timed it: it takes about 5 minutes using a free CloudFlare account. I can guarantee you that the majority of these people will do so the instant we add conneg to the spec. Most importantly, however, these these people are not the main target for the spec. They are not the ones for which applications will be built and an ecosystem will grow; they are not the ones to which we must cater.

I think you are under estimating the implementation burden here.  And how do you keep the different serializations in sync?
I think you are agreeing with me that it's a breaking change.  And you are trying to argue it's a minor change.  That is a subjective analysis, that I dont agree with.
But I thank you very much for taking the time to write this all out.  I do hope we can make progress.

How would this look for a compromise:

If you feel the changes are minor, then the new spec should be named with version 1.1 OR 2.0 but NOT 1.0.  And the CG can later come to a consensus on which

Work on extension profiles can continue in the group, unblocking new work, and reducing dependencies on an all-or-nothing solution

Why dont we just agree is a breaking change, and make that very clear, through versioning, then unblock everyone in the group that wants to make progress.  Sound reasonable?

I'm not agreeing at all. What I am trying to point out is that this is de facto a minor change (which is per definition not breaking), since none of the stakeholders at which this spec is aimed would be affected.
WebID is meant to provide an entry hook into the digital lives of people. To succeed in that, it will need the support of applications to become an ecosystem. That can only be achieved by being flexible on the server side.
The spec is NOT meant to serve the whims of some developers who want a static file and don't want to put in 5min of effort. If you want that, you can create another CG, though I doubt you will find many interested parties. But please stop setting your own desires above the aims of this group, who have finally come closer to consensus and are glad about it.

I think you are under estimating the implementation burden here. And how do you keep the different serializations in sync?

To shortly reply to this concern: as I said, I timed it, and it takes 5min. Keeping it in sync can be done with an automated script, which is about three lines of code. For example, as a GitHub workflow publishing to GitHub Pages, or using a tool like Soupault when running a static generator locally.

I think you are under estimating the implementation burden here. And how do you keep the different serializations in sync?

To shortly reply to this concern: as I said, I timed it, and it takes 5min. Keeping it in sync can be done with an automated script, which is about three lines of code. For example, as a GitHub workflow publishing to GitHub Pages, or using a tool like Soupault when running a static generator locally.

@webr3, what you are saying makes no sense. Did you even take the time to read the statistics I put effort in to gather?
All current providers support conneg with both formats. Why? Because it is a no-brainer. So stop pulling the "conneg is a burden" card, please.
As I have clarified elsewhere, I have no ties to Turtle other than backward compatibility (which, by the way, is exactly what @melvincarvalho is making such a ruckus about). I fully agree with you that, in some future, it is possible and probable that the spec can drop Turtle support. But it will do so with a decent deprecation strategy, and only after the ecosystem has gradually moved to JSON-LD. Moreover, since the data format landscape has historically proven to be a volatile one, having conneg present will in the even farther future be a practical once more to move from JSON-LD to whatever the majority will fancy then. This is how we build a spec that can outlive such changes.

So stop pulling the "conneg is a burden" card, please.

It's not only me:
See danbri, inventor of FOAF, that got the whole WebID movement going:
https://twitter.com/danbri/status/1080490927284736000
"the content negotiation aspect of linked data has been massively oversold"
I'm going to persist here, you will have to admit it's a breaking change in the case of alice.ttl or give me a reason why it is not.  After that, we can proceed.

@webr

Did you time conneging flat files, or did you implement something like a mongodb to turtle implementation with media type juggling that produces valid turtle in 5 mins?

Does it matter? The point is that those handful of people that want it can easily find ways to do it, and at least one of them is set up in a jiffy.
My test in particular was aimed at individuals hosting static files. So we're talking about pushing one format to GitHub Pages, having a workflow transpile to the other format, and setting up a Cloudflare rule that redirects to either of them depending on the Accept header.
For people setting up a database to host their (and presumably others) WebID data, adding conneg should even be less of a burden, relative to the time it already takes to set up the database in the first place.

So stop pulling the "conneg is a burden" card, please

It is. You offering proof of existing rdf conneg compatible systems doing what they do as "easy", of course it is, that's what they do.

That is not my argument. What I show is that, without the spec asking or even suggesting to do so, ALL WebID providers decided to add conneg. So either all of them happen to have massive resources on their hands, or adding conneg really isn't that hard... Which one would it be?

Whilst completely ignoring the requirement to turn non-rdf non-conneg systems in to doing all that, in order to adopt WebID. That is big, and it's very preclusive to adoption.
You cannot say that tiktok or Snapchat or FB quest Auth can just rdf-ize and conneg their systems "in 5 minutes" to adopt it.

I fully miss what your argument is here. The services you mention do not implement WebID at all. If they would want to do so, they would have to make an investment into RDF anyway. Adding conneg to that investment will be like adding one pea to a bag full of peas.

The point is being missed.
Conneg = super easy
Conneg to valid RDF = burdensome.

Oh, please explain...

at least one of them is set up in a jiffy

What is the URL?

Using JSON-LD without RDF stack is a thing, but unless you have numbers I don't believe for a second it is widespread. It's not like non-RDF services just happen to have JSON-LD WebID data lying around, and we're forcing them to actually treat it as RDF.
Moreover, even for players that want to enter the WebID ecosystem and up till then work with "non-RDF JSON-LD", adding the few lines of code to transpile valid JSON-LD to valid Turtle can hardly be called a burden.
You seem to have a grudge against Solid for some reason, but for all the years that WebID existed, they are the ones that actually put it on the map. As far as I know all WebID providers except OpenLink are primarily Solid businesses or organisations.

Wait, what kind of documents/domains are we talking about? Numbers mean nothing by just throwing them out without reference. These surely cannot be WebIDs or WebID-aspiring services?
I also don't see where you want this to go? WebID has been an RDF standard from the start. It currently is produced as Turtle, and I agree that consuming them as JSON-LD would be a benefit for lots of applications. That is precisely why we are proposing conneg. You surely are not saying that applications preferring JSON-LD cannot add an accept header to their requests?

To go into the only concrete example you gave: CMS's that can produce schema.org data (whatever that is).
Schema.org is (or at least pretends) to be an RDF vocabulary, so services producing such output produce RDF, willing or not (just like all JSON-LD is RDF). As I explained above, there is nothing preventing these systems to use one of the widely available RDF transpilers to output any other RDF format on request.
Moreover, I would actively dissuade anyone from using a CMS to host their WebID Document. They are absolutely not secure enough for such a central target in online authentication.

Anyway, I'm going to wait for others to chip in. I find it deplorable, however, that you would put a hard-reached consensus, of which you yourself said it was a way forward, on the line again.

@webr3, can I ask what the service is your client is providing? More particularly, I am curious as to why they would want to host WebIDs themselves.
As to the scalability of content negotiated RDF, multiple Solid stakeholders seem to disagree with you (given that they are doing it, I assume they believe it is possible). Without clear insight into your setup, or a benchmark to prove otherwise, I therefore still find it hard to believe.

/chair hat off

If you feel the changes are minor, then the new spec should be named with version 1.1 OR 2.0 but NOT 1.0.

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

WebID is meant to provide an entry hook into the digital lives of people. To succeed in that, it will need the support of applications to become an ecosystem. That can only be achieved by being flexible on the server side.

Yes, and this can be achieved  while also relegating content-negotiation to the implementation details level i.e., putting it in the implementation example (or techniques) section as one approach.
I agree with where you are headed, but content-negotiation doesn't need to be a part of the spec, since its just a technique afforded by HTTP re server implementation.

/chair hat on

If you feel the changes are minor, then the new spec should be named with version 1.1 OR 2.0 but NOT 1.0.

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

I appreciate the ongoing discussions and the commitment of everyone involved. I'd like to clarify my perspective regarding the recent propositions:

Proposal Context: Initially, the suggestion of simultaneously pursuing v2.0 or v1.1 alongside extension profiles seemed viable. However, my understanding evolved following the insights about the potential deprecation of Turtle.

Acknowledging Breaking Changes: It's crucial for the group, including Wouter, to recognize that mandating content negotiation (conneg) constitutes a significant modification. This point, I believe, should have been the preliminary observation. I've illustrated this in our discussions, yet I feel the responses have somewhat downplayed its impact.

Implications on Versioning: Acknowledging the substantial nature of these changes naturally leads to the question of versioning. Given the scale, it seems appropriate to consider this a move towards v2.0. The discourse isn't merely about introducing JSON-LD but about a gradual phase-out of Turtle, marking a substantial shift.

Consensus and Versioning Integrity: I'm concerned that the principle of lazy consensus might be misapplied to introduce significant alterations without the due process of version incrementation. For a spec that has reached a level of stability and fostered a wide ecosystem, any such major change warrants a more deliberate and inclusive consensus-building process.

Process and Controversy: The collective effort over the past six months was grounded in achieving a shared understanding of WebID, independent of serialization, which is foundational. The notion of extension profiles was an extension of this consensus, aiming to cater to diverse requirements. The shift in focus towards altering a stable spec, however, diverges from this path and delves into areas of long-standing debate. It's crucial to tread these waters with consensus and respect for the broader implications.

Path Forward: If we are to consider any significant changes or deprecation of Turtle, it necessitates broad consensus, including dialogues within the Solid WG. Such changes should be transparently proposed, with explicit versioning considerations. A living standard cannot be retrofitted with fundamental changes without a clear, collective agreement.

In summary, I urge us to:

Validate that mandating conneg and possibly deprecating Turtle indeed marks a breaking change.
Ensure any breaking change is accompanied by a major version increment.
Provide viable alternatives, such as extension profiles, to maintain a functional spec.
Engage the Solid WG and, ideally, seek insights from timbl regarding the deprecation of Turtle.

@jacoscaz, your leadership is invaluable, and this isn't a reflection on your chairmanship. Steering the direction of our work requires sensitivity to the foundational elements of the spec, and significant changes demand a proportionate consensus-building effort.  Changing things that have been in use for 10 years is going to be 10x more difficult than making progress on a new fresh, extensible, version of WebID for 2024, which gives everyone what they want.

I think you are under estimating the implementation burden here. And how do you keep the different serializations in sync?

@melvincarvalho respectfully, this quote alone proves that you don't understand how RDF-aware applications are built.
No serious Linked Data application would store RDF as documents, with a copy per media type. Which would lead to issues like them going out of sync.
RDF is being stored as triples in a triplestore, an abstract graph model that has no inherent syntax. Only upon HTTP response the right media type is chosen using conneg and used to serialize the response body. Conneg is automatically handled by the HTTP framework such as Jersey. Switching serializations is as simply as passing different media types to Jena's I/O. From the client perspective there are still documents, but they are generated on the fly (and can be cached of course).

Now lets try to illustrate this issue with some examples:
WebID 1.0 request/response
GET alice.ttl
Accept: application/ld+json, text/turtle, */*;q=0.8

200 OK
Content-Type: text/turtle

WebID 2.0 request/response
GET alice.ttl
Accept: application/ld+json, text/turtle, */*;q=0.8

200 OK
Content-Type: text/turtle

It looks to me that the same headers would work with both WebID 1.0 and 2.0?

respectfully, this quote alone proves that you don't understand how RDF-aware applications are built.

@namedgraph this is not respectful.  I have coded many RDF-aware applications.  It's an ad hominem attack and unprofessional.  Please retract.

OK, comment updated

no serious Linked Data application would store RDF as documents

Sure they would.  Linked Data is just another name for the Semantic Web.  It's about having machine and human readable documents on the web, including with hyperlinks.
The style you may be your personal preference, but you need not project that preference onto others.
Let me ask you, how many daily active users do your Linked Data applications have (or monthly if daily=0).  What do they use them for?  Why do you consider your view to be a universal one, who are you representing?
Id suggest making your tone more subjective, since there are obviously a range or publishing techniques in RDF.

Now lets try to illustrate this issue with some examples:
WebID 1.0 request/response
GET alice.ttl
Accept: application/ld+json, text/turtle, */*;q=0.8

200 OK
Content-Type: text/turtle

WebID 2.0 request/response
GET alice.ttl
Accept: application/ld+json, text/turtle, */*;q=0.8

200 OK
Content-Type: text/turtle

It looks to me that the same headers would work with both WebID 1.0 and 2.0?

If the application is expecting JSON-LD then the turtle only response will fail.  That's why JSON-LD=MUST is a breaking change.

If the application is expecting JSON-LD then the turtle only response will fail. That's why JSON-LD=MUST is a breaking change.

Exaclty. This is why we need conneg.

If the application is expecting JSON-LD then the turtle only response will fail. That's why JSON-LD=MUST is a breaking change.

Exactly. This is why we need conneg.

I believe conneg is implied here.  But this issue is simply proving, in a pseudo-mathematical, sense that mandating conneg (implicitly or explicit) via dual MUSTs for Turlte AND JSON-LD is a breaking change.  I think it's something we could agree on.

It looks to me that the same headers would work with both WebID 1.0 and 2.0?

If the application is expecting JSON-LD then the turtle only response will fail. That's why JSON-LD=MUST is a breaking change.

Isn't WebID 2.0 mandating both JSON-LD and Turtle? In which case the client should be able to handle both.

no serious Linked Data application would store RDF as documents

Sure they would. Linked Data is just another name for the Semantic Web. It's about having machine and human readable documents on the web, including with hyperlinks.
The style you may be your personal preference, but you need not project that preference onto others.

Melvin, this is not even RDF or Semantic Web specific. There was a time 20-30 years ago where websites consisted of static HTML documents. Nowadays the absolute majority of webpages and API responses are generated from databases on the fly, as I'm sure you would agree.
The same applies to Linked Data, where the database is the triplestore. RDF has an additional advantage of offering a number of syntaxes for the same graph content, and conneg allows clients to choose them.

Let me ask you, how many daily active users do your Linked Data applications have (or monthly if daily=0). What do they use them for? Why do you consider your view to be a universal one, who are you representing?

It's hard to tell what the users are using our software for, but it does have 450+ GH stars at the moment: https://github.com/AtomGraph/LinkedDataHub
It has supported conneg for 10+ years since the project that was an early prototype of LinkedDataHub.

Id suggest making your tone more subjective, since there are obviously a range or publishing techniques in RDF.

@namedgraph thanks for the additional context.  That is a reasonable deployment.  Yet I dont think you speak for everyone.  It's absolutely legitimate to have documents on the web, that's how the web started, and how millions of people use the web.
Do you agree that the addition of conneg=MUST is a breaking change on the server side?
Clients may only support 1 of 2 serializations.  And, as wouter says, turtle itself my be deprecated.

It looks to me that the same headers would work with both WebID 1.0 and 2.0?

If the application is expecting JSON-LD then the turtle only response will fail. That's why JSON-LD=MUST is a breaking change.

Isn't WebID 2.0 mandating both JSON-LD and Turtle? In which case the client should be able to handle both.

Client only needs to be able to handle 1 if the server handles both.  There's the point of breakage.

Melvin I think I know what you're hinting at but I still don't agree.
You are suggesting a situation where a client only supports JSON-LD, correct?
Well first of all it shouldn't request Turtle if it cannot handle it. Lets model that:
GET alice.ttl
Accept: application/ld+json

406 Not Acceptable

Like this? Yes JSON-LD-only client would fail to load the Turtle data in this case. But that would also be the case with WebID 1.0, so I don't understand what you think changes here?

Melvin I think I know what you're hinting at but I still don't agree.
You are suggesting a situation where a client only supports JSON-LD, correct? Well first of all it shouldn't request Turtle if it cannot handle it. Lets model that:
GET alice.ttl
Accept: application/ld+json

406 Not Acceptable

Like this? Yes JSON-LD-only client would fail to load the Turtle data in this case. But that would also be the case with WebID 1.0, so I don't understand what you think changes here?

Yes, exactly.
In WebID 1.0 everything works because you have a common ground, namely, turlte.
If there is a change to BOTH turtle and JSON-LD being MUST (e.g. via conneg) then the client can be either turlte or json.
That means that webid 1.0 will not work with the new webid 2.0.  Hence its a breaking change.

I would argue (as I've done before) that the issue here is that 1.0 specified any serialization at all, in this case Turtle. Because we're talking about an orthogonal HTTP/conneg issue that is not specific to WebID.
TL;DR: clients and servers might negotiate and might not find an acceptable serialization, and that is simply a common HTTP error and not a WebID compliance issue
In other words, conneg is the solution here, not the problem. The server has a set of media types it can read/write, as does the client. Conneg allows them to find an intersection between those sets, or if there is none, leads to an error. And that works perfectly transparently -- until someone puts some text in a specification like WebID that some specific serialization MUST be supported, which breaks the orthogonality.

/chair hat on

If you feel the changes are minor, then the new spec should be named with version 1.1 OR 2.0 but NOT 1.0.

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

Concretely, there are multiple aspects

Advocacy for Status Quo: as expressed in the call for a complete freeze. This stance acknowledges the longstanding impasse within the group. However, I also appreciate that the formation of a Solid WG could introduce pivotal change, potentially dissolving the freeze.

Versioning for New Initiatives: I suggest that any new endeavors stemming from the WebID ED 2014 adopt a fresh versioning approach. This clear demarcation would properly represent the involvement of new authors, editors, and methodologies. For substantial revisions, version 2.0 seems fitting, whereas 1.x might suit more incremental updates. It's worth noting that introducing mandatory content negotiation (conneg) is a significant alteration and should be treated as such in versioning.  This issue is about proving that the change clearly is breaking.

Personal Stance on Conneg: On a personal note, the push towards mandatory conneg is a significant shift that I find challenging to align with, and could not live with, if it was the only choice. That said, exploring the development of a JSON-LD extension profile. Detailed guidance on its implementation, naming conventions, and structure would offer a constructive pathway. This approach would also allow those inclined towards a conneg path to proceed independently, ensuring diverse yet harmonious development within the community.

I hope that is clear enough.  It can be revisited this when the Solid WG starts up.  Mandating conneg is by far the most controversial change that has been suggested to the group in many years.   Replacing RDFa with JSON-LD and structured data islands would have been far easier.  If you want to make a new draft, with new authors, and a new set of defaults, bump the version to 2.0, and see if it stands on its own merits.

I would argue (as I've done before) that the issue here is that 1.0 specified any serialization at all, in this case Turtle. Because we're talking about an orthogonal HTTP/conneg issue that is not specific to WebID.

So, Turtle was specifically chosen as a MUST in WebID 1.0 because it guarantees interop.
The vast majority of the web does not use conneg.  And WebID is designed as a "Web" technology.
Yuo need a common ground so that everything works together.
Turtle was chosen, maybe that was a mistake in retrospect, but it was the decision taken.  A change to that would be breaking.

On the flip side, WebID document resolution depends on HTTP (as does the rest of the web) and HTTP supports conneg by default. So yes, it was a mistake to attempt to override the default HTTP behaviour because it was clearly out of scope for the WebID spec.
That has now put us in a bind trying to satisfy conflicting requirements: Turtle is MUST due to backwards compatibility with 1.0, and JSON-LD is MUST due to new requirements. I don't see how these can be reconciled in the light of your example.

Turtle was chosen, maybe that was a mistake in retrospect, but it was the decision taken. A change to that would be breaking.

If we would relax the serialization requirements by removing Turtle, i.e. removing them altogether, how would that break the backwards compatibility?

Turtle was chosen, maybe that was a mistake in retrospect, but it was the decision taken. A change to that would be breaking.

If we would relax the serialization requirements by removing Turtle, i.e. removing them altogether, how would that break the backwards compatibility?

Because there's no common ground for libraries to ensure everything works for all users.  That's why ONE serialization was selected.  Turtle just seemed a good choice at the time.

That was then, but I'm
talking about making a change now.
No other spec in the RDF stack such as SPARQL or SHACL specifies any mandatory RDF serializations, because it is understood it's a completely orthogonal concern.

That was then, but I'm talking about making a change now.
No other spec in the RDF stack such as SPARQL or SHACL specifies any mandatory RDF serializations, because it is understood it's a completely orthogonal concern.

I believe solid does.
I've sent a message to the Solid CG to see if anyone has strong views on Turtle vs JSON-LD:
https://lists.w3.org/Archives/Public/public-solid/2024Feb/0001.html
Let's see what they say.

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

Perhaps its helpful to give some background.  WebID was in development for 5+ years before it got to 1.0 in 2014.  Longer if you consider foaf and foaf-protocols before it.
The reason it was called 1.0 rather than 0.x was because it was considered finished, stable, and ready to use by the authors.  That proved to be the case as we spent many years building Solid on top of it.  The only reason it didnt become a REC was because of an arbitrary decision of LDP not to include identity in the first version.  There was then an idea it could become a REC in the Solid WG.
That's why it's 1.0 and not 0.10 etc.  Note Solid is still in the 0.x phase which indicates that 0.x+1 can change bits.  1.0 was an indicator of stability and completion and it has been so for 10 years.
Any new work with new authors/editors/methodology should respect that by starting at 1.1 under all scenarios.  It's just far too confusing to do anything else.  Minor changes could be put into a 1.1 spec and subsequently published.  The main thing that I see is that JSON-LD could be put on the same footing as RDFa as a MAY.  In fact RDFa should be replaced with JSON-LD IMHO.   That I can see being a non-obtrusive 1.1 release.
Any major breaking changes should be 2.x, and conneg being mandated falls under that category.
The only scenario I can see where something different could apply would be if everyone, including the Solid WG had a unanimous agreement to redefine the concept in order to make it a W3C REC.  But we dont have word from the Solid WG yet, so that seems premature.
Let's do proper versioning based on breaking changes, and to show respect to the authors that came before who felt, understandably, that they had made something finished and ready to use.  I hope that adds some extra clarity.

If we would relax the serialization requirements by removing Turtle, i.e. removing them altogether, how would that break the backwards compatibility?

Timbl was very insistent on having at least one MUST.  Basically it means that all clients and servers can ensure a consistent UX for the eco system.
Let's say you dropped turlte, and then one group wanted RDF/XML another n3.  End users would not know what was happening.

/chair hat on
There are a few things that I would kindly ask everyone to stop and think about before continuing this conversation.
Quoting from this comment:

All existing WebID providers (Inrupt, Use.ID, OpenLink, solidweb.me, redpencil.io, inrupt.net, solidcommunity.net ...) already provide Turtle+JSON-LD through conneg.

Quoting from this comment:

I've search through the 6p of NPM packages that use the term "WebID" in their description, and looked into their actual code. Here are the numbers:

Only 7 packages actually looked up a WebID Document.
Only 2 packages them are popular (>10 downloads/week):

@inrupt/solid-client-js (9,433): requests & parses Turtle (though caller code can pass in another parser).
@solid/access-token-verifier(395): requests & parses Turtle

71.4% (5/7) only request & parse Turtle
Only 2 hardly used packages can parse something else:

webid-pubkey-credentials-module(3): requests unspecified & parses any RDF format
node-webid (0): requests Turtle or JSON-LD & parses any RDF format

webid-provider-tests (of the Solid CGs official test suite): requests & parses Turtle

Again, in as far as these numbers tell us anything, they clearly indicate the predominant presence of Turtle as expected WebID format, not only in absolute numbers, but especially through the strong reliance on a limited set of libraries that use Turtle.

Unless anyone can refute the above, the only practical breaking change that would be introduced by a MUST on Turtle and JSON-LD for publishers would be to make statically hosted WebID Profile Documents in the form of Turtle .ttl files non-compliant.
This is, indeed, a breaking change, albeit a minor one if we weigh it against the number of occurrences of this particular hosting scenario. Nonetheless, it deserves to be called for what it is - breaking. If we were dealing with a WG aiming to push forward with the next version of a published spec, this would amply justify a version increase.
However, as the 2014 ED itself reminds us, there is no such a thing as WebID 1.0:

This document is produced from work by the W3C WebID Community Group. This is an internal draft document and may not even end up being officially published. It may also be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. The source code for this document is available at the following URI: https://dvcs.w3.org/hg/WebID

In fact, any WG that adopted our drafts would be in charge of producing exactly that, the first published, official version of the WebID spec: Web Identity and Discovery (WebID) 1.0 . Adding a version number other than 1.0 to our drafts makes absolutely no sense, if only for the fact that the first official version of the spec would see that number decrease back to 1.0.
Nonetheless, given that we are dealing with a breaking change, we do need to provide some way to easily discriminate the working draft from the 2014 ED. Luckily enough, this is how the 2014 ED looks, both in this repo and in the old incubator pages:

Though it has been around for a long time, any adopter of the WebID 2014 ED who has actually taken the time to even simply glance at the spec from a distance is already aware of its nature as an ED because the ED itself makes that crystal clear.
There is no reason to hold back on a breaking change, if there is consensus behind it, as long as we produce a document that can be easily told apart from the 2014 ED. As the screenshot above demonstrates, that's more than easily achieved by simply changing the date.
This is how I'm going to move forward, as chair. If any of you were to find it unpalatable, I invite you to a) refute any of the above in a clear, demonstrable, replicable, grounded manner and b) ask me to resign. I serve the group and, if the group deems it so, I'm happy to step down and let someone else carry things forward.

This is, indeed, a breaking change,

Thank you very much for confirming this.  That was the purpose of the issue.
Also thank you for considering all the nuanced viewpoints and reaching that conclusion.  IMHO an example of good chairing.
I am saying very clearly that I do not want breaking changes to the spec that we have, no matter how slight they care considered by some, there is clearly a spectrum of views on how big a change it is.  I personally feel it's the biggest breaking suggestion we've had in years.

There is no reason to hold back on a breaking change

I disagree on this completely.  You do NOT have consensus.

This is how I'm going to move forward, as chair.

You cannot railroad breaking changes through to a mature, in use, 10 year stable spec, which has a eco systems built up around it, without full consensus.
I simply ask you to focus on items with consensus.

As the screenshot above demonstrates, that's more than easily achieved by simply changing the date.

You honestly lost me completely wtth this.

It clearly says WebID 1.0 on your own diagram.  It was considered finished, complete and ready for production by the authors.  Changing the date to shoe-horn in breaking changes is a non-starter.

This issue can now be closed, I think we've all expressed ourselves.
We can move forward having proved, and with a group consensus that introducing JSON-LD=MUST and/or conneg=MUST is a breaking change.
It goes without saying that breaking changes are a high, or perhaps the highest, level of controversial changes a group can have.
How we move forward I think is an orthogonal conversation.
So I suggest closing in this in a bit, unless someone wants to try and argue that it's not a breaking change.  Else we can move forward with a shared understanding which I think will enable progress.

You cannot railroad breaking changes through to a mature, in use, 10 year stable spec, which has a eco systems built up around it, without full consensus.

@melvincarvalho at this point I'm not going to spend any further time on arguing about whether I'm railroading anything or not. Fortunately, everything we do is on record, for everyone to see. You have the right to draw your own conclusions, of course, and I respect that. We obviously disagree on many things, which is also absolutely fine, but I do not have it in myself to continue this manner of interaction as I'm aware that I would become more adversarial than anyone ought to be in their professional (and, IMHO, personal) conduct.
I'm going to move forward following the principles that I've laid out in https://github.com/w3c/WebID/issues/58#issuecomment-1925809369 unless someone refutes them in a clear, demonstrable, replicable, grounded manner and/or the group asks me to step down.

@melvincarvalho at this point I'm not going to spend any further time on arguing about whether I'm railroading anything or not. Fortunately, everything we do is on record, for everyone to see. You have the right to draw your own conclusions, of course, and I respect that. We obviously disagree on many things, which is also absolutely fine, but I do not have it in myself to continue this manner of interaction as I'm aware that I would become more adversarial than anyone ought to be in their professional (and, IMHO, personal) conduct.
I'm going to move forward following the principles that I've laid out in #58 (comment) unless someone refutes them in a clear, demonstrable, replicable, grounded manner and/or the group asks me to step down.

You do not have consensus for that.  I would appreciate if you would at least acknowledge that.

Counter proposal.  Why not do things that went through the hard multi-month, multi year process of gaining consensus such as the superspec, and extension profiles?

You do not have consensus for breaking changes.  I would appreciate if you would at least acknowledge that.

Counter proposal.  Why not do things that are non-breaking, or completely new work?

You do not have consensus to reuse the existing 1.0 version number for your newly edited work.  I would appreciate if you would at least acknowledge that.

Counter proposal: bump the version number so that ALL can see the difference.  Why cant you do this?  You didnt write WebID 1.0, what claim do you have to it?

You have yet to receive consensus from future Solid WG for your changes.  I would appreciate if you would at least acknowledge that.

Counter proposal:  why not be patient and wait for Solid WG to start up, and engage with them, ask them what they want.  See if they want WebID to be a REC?  Why does it have to be so rushed through (you perhaps dont like my use of the word railroading, so i could withdraw it, and say "rushed", is that better?)
How you proceed is up to you.  But I will say that you have a close to perfect track record so far.  I can only ask you take consensus into account with your decisions, and Im optimistic that you will.
I would urge you to focus on the items where you do have consensus.  IMHO you've done a fantastic job so far.  You've just pivoted from the tricky task of making WebID modular and useful, to the impossible task of trying to gain the most difficult consensus that has not been achieved in years, and proposing the biggest change.
I'd entourage you to take the low hanging fruit.

Sure they would. Linked Data is just another name for the Semantic Web. It's about having machine and human readable documents on the web, including with hyperlinks.

Linked Data isn't another name for the Semantic Web.
Linked Data is simple a principled approach to structured data representation that CAN manifest a Semantic Web.  The rules are simple:

Name anything of interest using an HTTP URI.
Describe said item of interest using RDF sentences/statements -- where subjects and predicates are denoted by an HTTP URI, while objects are denoted by an HTTP URI or literals (which may be typed or untyped).

A Semantic Web is an entity relationship graph comprising machine-readable (or computable) entity relationship type semantics -- informed by an Ontology.
Thus, you can create a basic "Web of Data" using Linked Data principles without links that denote terms in an Ontology (the key to machine-readable entity relationship type semantics).

provide examples in multiple mediatypes (extension profiles).

Examples can be provided in the specs too, without the need for profiles.
The issue right now is that the old spec conflates too many things, for all the wrong reasons.

Ive suggested this as a possible direction to take.
https://lists.w3.org/Archives/Public/public-webid/2024Feb/0002.html

This is how I'm going to move forward, as chair. If any of you were to find it unpalatable, I invite you to a) refute any of the above in a clear, demonstrable, replicable, grounded manner and b) ask me to resign. I serve the group and, if the group deems it so, I'm happy to step down and let someone else carry things forward.

Your leadership as chair has been nothing short of remarkable, propelling us to unprecedented achievements this quarter. Your ability to discern and address legitimate concerns has been a key factor in our success.
However, I would much rather suggest a pause, than anything more drastic.   In order to allow the soon-to-form Solid WG to shape, and they can inform us with vital new information. Taking a well-deserved break might be far preferable to resigning or prematurely tackling highly controversial items.  The problems then start to fix themselves in Q2 of 2024 when there will be clarity, where before there was none.
The progress we've made under your guidance is undeniable, and what is needed is a serialization and implementation neutral way to define and specify WebID.  Conversely, without that shared understanding, we stand almost no chance of creating a consensus based specification.  So the only thing needed here is to do things in the right order, and if in doubt, to slow down.  I appreciate that is easier said than done, and that you take pride in your work.  But let's build on success in a low-risk way, rather than taking the (unnecessary) high risk path to premature failure.

slowing down or pausing

Indeed. 65 comments on one new issue over a weekend. Plus at least two significant email threads. And other (long!) issue discussions besides.
It's great that some people are able to devote all their waking time to such. I am not one of those people.
Slowing down, giving time for readers to consider and respond to comments/posts, would not only be a good idea, I think it a necessity. Else, this may well turn into a 5-ish person round-robin, the output of which may not find general consensus among those in the CG (or eventual WG), never mind eventual team review for transition to REC.

Discussions are fine, as they refine understanding.  For example it was unclear before this issue, that proposed changes to add JSON-LD and conneg as a MUST were a breaking change.
This issue has established that the proposed changes are indeed a breaking change
What should be slowed or paused is breaking changes being applied to WebID.  I have advocated for a freeze for some time, until we can, as a group, come up with a serialization and implementation neutral way to define and specify WebID.  Something that we as a group should have done years ago.
If that can be achieved in Q1 of 2023, or even Q2 (there is no rush).  It would be a valuable documentation that lives on its own merits.  Then, and only then, is it logical to discuss serialization preferences.

It's great that some people are able to devote all their waking time to such.

@TallTed please, be respectful.  Your tone is inappropriate.  Passive aggressive micro-aggressions add nothing constructive to the conversation.

Really, @melvincarvalho? This is not an issue. @jacoscaz, I suggest moving this to Discussions, which we specifically opened for things like this.

I dont mind at this point if this is converted to a discussion, or closed, having established the main premise.

/chair hat on

Else, this may well turn into a 5-ish person round-robin, the output of which may not find general consensus among those in the CG (or eventual WG), never mind eventual team review for transition to REC.

@TallTed and all: we do have a process in place that guarantees review times of up to 4 weeks for breaking changes and I remain steadfast in my quest for unanimity first and, if that cannot be achieved, as large a consensus as we can muster. While conversation can happen in bursts and evolve quickly, this doesn't automatically extend to how changes are made.

Else, this may well turn into a 5-ish person round-robin, the output of which may not find general consensus among those in the CG (or eventual WG), never mind eventual team review for transition to REC.

There's really no risk of this happening as long as we stick to the process we have in place. While I do share a certain frustration with how parts of the conversation are being brought forward, at the present moment there's no risk of anything being decided against general consensus.

@TallTed and all: we do have a process in place that guarantees review times of up to 4 weeks for breaking changes and I remain steadfast in my quest for unanimity first and, if that cannot be achieved, as large a consensus as we can muster. While conversation can happen in bursts and evolve quickly, this doesn't automatically extend to how changes are made.
There's really no risk of this happening as long as we stick to the process we have in place. While I do share a certain frustration with how parts of the conversation are being brought forward, at the present moment there's no risk of anything being decided against general consensus.

In response to your message, I'd like to express my concerns with utmost respect but with necessary candor. The current approach to implementing substantial changes in a well-established, decade-old project raises significant apprehensions. Introducing major modifications without a more inclusive timeline for feedback disregards the extensive ecosystems and toolings that have matured over the years. Such a brief window for feedback, especially when it risks overlooking substantial objections, seems incongruous with the collaborative spirit and technical stability we've cherished.
Moreover, the decision to not revise the version number amidst these changes is perplexing. Maintaining the version as 1.0, despite fundamental alterations, not only confuses but also undermines the integrity of the project's evolution.
Crucially, the prioritization of this fork over the foundational task of defining WebID in a serialization-neutral manner contradicts the collective wisdom of the group. This leapfrogs the essential step of establishing a common understanding of WebID, crucial for ensuring compatibility and coherence across the board.
Additionally, the timing of these changes is particularly troubling. Forcing this transition in the narrow timeframe before the inception of the Solid WG deprives a significant stakeholder of their rightful input, potentially alienating a key segment of our community.
While change is inevitable and often necessary, the manner and sequence in which it is executed bear profound implications. The convergence of these concerns – the haste of implementation, disregard for versioning semantics, inversion of priority over serialization neutrality, and the ill-timed scheduling – collectively signify a departure from the principles of inclusivity, foresight, and respect for the community's legacy and future.
It is with a sense of responsibility towards the project's long-term health and community cohesion that I voice these objections. In the spirit of constructive dialogue and shared commitment to the project's success, I urge a reconsideration of the approach to ensure that it aligns with our collective aspirations and principles.

/chair hat on
@melvincarvalho I don't like to ignore people but I can't keep addressing the same points ad infinitum. I will do so once again, here, and then stop answering to any further mention of these specific issues from you.

the haste of implementation

So far, the only actual changes I've merged in since I became chair are:

Formalizing our process and making it explicit.
Conversion to BikeShed.
Intended audience.

Other than this, the only thing I've done is trying to foster and locate consensus (see #37). I can't see how any of this classifies as haste (or implementation!).
If you believe that 4 weeks are not enough for major PRs to be adequately discussed, why don't you adopt a more proactive stance and propose a change to our process?

disregard for versioning semantics

I've already made my point in https://github.com/w3c/WebID/issues/58#issuecomment-1925809369 . The 2014 ED states very clearly its own nature as an ED. You disagree, and I respect that, but I'm not going to change my mind just because you keep making these accusations.

inversion of priority over serialization neutrality

At some point you will have to accept that not everyone believes in serialization neutrality. I can't do much more than quote a couple of recent posts to make you understand that, as chair, I can't just go with what you (or I, for that matter) want.

https://github.com/w3c/WebID/issues/3#issuecomment-1879750583
https://github.com/w3c/WebID/issues/17#issuecomment-1877196126

Forcing this transition in the narrow timeframe before the inception of the Solid WG deprives a significant stakeholder of their rightful input

Solid people are welcome to join in the conversation here. Nobody is blocking them from doing so. In fact, I've been actively trying to reach out to them but, if I had to guess, they do not believe participation in this group to be a productive endeavor - and that is on all of us. I would like to prove them wrong and have them join the conversation once again but I can't do that on my own.
If you find any of my answers to be unacceptable, I beg you to please make the case for my resignation rather than continuing this manner of interaction. I understand disagreement and I would not think any less of you if you were to do so. I've said this many times: I'm happy to step down if the group would rather have someone else.

I am asking you to prioritize things in the right order.

define and specify webid, then select serialzations -- success
select serializations before webid is defined -- split group, and both halves fail

Its simply an ordering problem.
Build the house then build the bathroom.  Dont build the bathroom then build the house.
The failure here is to understand that serializations can be selected after WebID is defined.
Just as SPARQL can be defined then used with any number of serializations.  But SPARQL cant be used with any serializations, before it is specified.
I need you to acknowledge the logic of the two step approach being consistent with everyone's needs.  Arguing that Turtle=MUST PRECLUDES defining defining WebID just is not a serious argument.  Defining and specifying WebID ENABLES the serialization conversation.
We just have to avoid putting the cart before the horse.  Specify WebID and everything else follows.

What is the

@woutermont I'll not you've not yet provided a URL for the implementation that you outlined.  Does it still exist?

Let me add the mail list comments from Ruben Taelman:
https://lists.w3.org/Archives/Public/public-webid/2024Feb/0047.html

I just want to briefly chime in and say that the “MUST on Turtle and JSON-LD on publishers”
may represent consensus among the loudest and most present voices in this CG,
but it may not necessarily represent what less vocal people may be looking for.

But I strongly agree with Martynas’ comment on that WebID should be orthogonal to what RDF serialization is used.
WebID and RDF serialzation apply to different locations when observed in a layered structure.
It’s like expecting HTTP to suddenly start requiring at least WiFi 802.11ac to be used, these are orthogonal things.

emphasis mine.

This issue can now be closed, having proved sufficiently, that mandating conneg (e.g. via JSON-LD AND Turtle = MUST), is a breaking-change.

Solid people are welcome to join in the conversation here. Nobody is blocking them from doing so. In fact, I've been actively trying to reach out to them but, if I had to guess, they do not believe participation in this group to be a productive endeavor - and that is on all of us. I would like to prove them wrong and have them join the conversation once again but I can't do that on my own.

You're severely mistaken.
All, if not, vast majority (perhaps except you) of the active/substantial contributors here are literally involved in Solid and in general have been driving the RWW space forward.
I for one helped to get the work continue in this repository so that the stalled work in the WebID CG can continue. You can read a brief background at https://github.com/w3c/WebID/issues/5#issue-1153260476 . I've also put in effort to work to continue even further in a W3C Recommendation track through the Solid WG charter proposal ( see proposal: https://github.com/solid/solid-wg-charter/issues/39#issue-1741064792 https://github.com/solid/solid-wg-charter/issues/39#issuecomment-1580886272 ) and efforts to unify communities. I've created/connected various issues/PRs, did all the open "grunt" editorial work (when no one even approached it for years.)
And I can refer to numerous other contributions from "Solid people" if that doesn't suffice. Your assertions are not only significantly mistaken, but I find it impolite. It is not you that needs to welcome "Solid people". "Solid people" have been active participants in this community long before your arrival, and if anyhting, it is they who welcomed you.
Start by speaking for yourself ( see WebID CG communication guidelines borrowed from Solid CG's contribution guidelines) instead of chalking up a whole set of participants as to what they think or don't about the current state of affairs.
Consider reading your statements again after perhaps considering the possibility that you may be in fact ignoring or downplaying recommendations that are spelled out from the start; clearly demonstrating "NIH"; anything and everything from chairing to editing..

However, I would much rather suggest slowing down or pausing, rather than anything more drastic. In order to allow the soon-to-form Solid WG to shape, and they can inform us with vital new information.

Wishing to address this.  We have new information, the Solid WG is delayed and changing to the PUMPKIN WG.  That means that the original consideration of waiting for clarity on that.  We now have that clarity.  We need not be too heavily held up by PUMPKIN WG as it is unclear that they are near forming a WG, let alone taking WebID to REC.

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

For the record, yes I think I could live with that, at this point.  Removing blockers to new work.

And I can refer to numerous other contributions from "Solid people" if that doesn't suffice. Your assertions are not only significantly mistaken, but I find it impolite. It is not you that needs to welcome "Solid people". "Solid people" have been active participants in this community long before your arrival, and if anyhting, it is they who welcomed you.

@csarven please be respectful, and operate in good faith.  The tone here is not the best.  @jacoscaz has worked very hard to be inclusive.

Consider reading your statements again after perhaps considering the possibility that you may be in fact ignoring or downplaying recommendations that are spelled out from the start; clearly demonstrating "NIH"; anything and everything from chairing to editing..

This is off-topic, and inappropriate.

You're severely mistaken.
All, if not, vast majority (perhaps except you) of the active/substantial contributors here are literally involved in Solid and in general have been driving the RWW space forward.

Again tone could be better.  Obviously there's quite an overlap with RWW, WebID and Solid (now PUMPKIN).  IMHO your ambition to be chair of the Solid WG was one more issue that it needed to handle.  You could achieve everything you wanted as an IE rather than a chair.  There wasnt a need to push for objections on the Solid WG based on chairs, when there were two perfectly good ones.  Let's put the animosity to one side and work together to make a better web.


(feat) adds tool tips to selection table

merging from nightly into nightly; @haochuanwei will check and approve if it passes

Looks like nightly has its own tests to update. We will merge this now as it could not have introduced the particular errors seen in the tests.


[Android] Custom Fonts Not Working

Opening a new issue since the discussion on #1167 seems out of place (closed/iOS issue).
Custom font files are not loading on Android.
I've tried putting the .ttf (and .otf) files in both /assets and /assets/fonts (I had to the do the latter in a native Android project). And then I declare text like so:
<Text style={{fontFamily: 'FuturaStd-ExtraBold'}}>Hello World</Text>

And just for the record - I'm using the same exact font files and declaring <Text> the exact same way in an iOS React Native project and they are working.
The workaround suggested in the referenced issue seems to simply replace the default app font with a custom font file. This is not sufficient as I need multiple different custom fonts in my app.

@andreicoman11 Is fontFamily supported on Android?

We don't currently support loading custom fonts from assets.

Is there a workaround that we can use. It would help a lot if this information is listed on the React Native Docs ;)

+1 We are using Icon Fonts a lot and desperately need this feature. Unfortunately react-native-icons is not yet working on Android either :(
Please help enable this feature.
Thank you
Bernd

@BerndWessels We should have this feature but might take a while until we have bandwidth to look into it. Would you be up for sending a pull request?

I will have a look into it, but hopefully a "real" Android expert can come up with something, since I am not very experienced on the native site.

@mkonicek I was considering doing a PR for this, since most of the typeface stuff on Android is encapsulated in CustomStyleSpan.java I'm curious on some of the core team members thoughts on where fonts should be loaded from assets.
Since this requires a context it would have to happen elsewhere and I'm assuming we would want a global Typeface cache as well.
Typeface.createFromAsset(getContext(), "customfont.ttf");

Thanks for looking into this!
You need the AssetManager from the context in order to load the custom font. You can get it by:

add a ReactTextViewManager constructor that gets the context from the package
get the AssetManager from the context and pass it to the constructor of ReactTextShadowNode
give the AssetManager from the ReactTextShadowNode to the CustomStyleSpan constructor
get the new Typeface in the CustomStyleSpan constructor and cache it in the existing typeface cache
@kmagiera do you know if there's anything wrong with this/if it can be done in a better way without passing the Context to the ShadowNodes?

That was my main concern, whether I should be passing the context all the way down into the shadow node itself
On Thu, Oct 1, 2015 at 4:29 PM, Andrei-Ovidiu Coman
<EMAIL_ADDRESS>wrote:

Thanks for looking into this!
You need the AssetManager from the context in order to load the custom font. You can get it by:

add a ReactTextViewManager constructor that gets the context from the package
get the AssetManager from the context and pass it to the constructor of ReactTextShadowNode
give the AssetManager from the ReactTextShadowNode to the CustomStyleSpan constructor
get the new Typeface in the CustomStyleSpan constructor and cache it in the existing typeface cache
@kmagiera do you know if there's anything wrong with this/if it can be done in a better way without passing the Context to the ShadowNodes?

Reply to this email directly or view it on GitHub:
https://github.com/facebook/react-native/issues/2919#issuecomment-144866341

As mentioned in this comment, perhaps we can load custom fonts by calling (new) methods on ReactInstanceManager, that associate a fontFamily name with a .ttf file?

Added in https://github.com/facebook/react-native/commit/bfeaa6a4f531cfc18c097bc9ffb6a8dbe3ddc702


API Documentation Group 3 : File I/O Function 8 : File Read Typo

Parameters:2,3 contains the amount of data to read. Should be: Parameters:3,4 contains the amount of data to read.

Moved to neo6502-firmware as the API documentation is done with markup code in the source.


Inconsistent with the original dataset

Hi,
May I know how did you calculate the statistics for user numbers? They are different from the original paper which published the dataset you used.

@WenMellors

Actually, I don't know anything about this. I downloaded this data from Dingqi Yang's homepage. During processing, I did not delete the data. Only one mistake is that Geo's stats are undercounted by one, because I overlooked that we start numbering from 0. In the paper, the author eliminated inactive users, which may be a reson caused by this operation.


Ignore SLAAC privacy addresses?

I've recently started using cloudflare-dynamic-dns to publish my server's IPv6 address, and it's working very well with one caveat.
On any modern OS using SLAAC, the privacy extension will be turned on by default, which causes short lived random addresses to be generated for the interface to be used to anonymize outgoing traffic. These addresses are not practically usable as the IP behind our DNS names because they change all the time. Rather, we want to register the stable EUI-64 address based on the MAC address.
Today, the tool's default behaviour causes it to pick any assigned address at random, as they are all equally acceptable for the current logic - they have the same subnet prefix, etc.
To make it pick the EUI-64 address, I had to use a /72 priority subnet prefix that incorporates the first part of the stable EUI-64 address. This works, but it now means I've had to hard-code the /64 that my ISP assigned me, and if that changes, my configuration would need to be manually changed as well.
Ideally, the tool would be able to prioritize the EUI-64 address (by matching against the interface MAC address) automatically.
Thanks!

Hey @philipl, I finally got some time to look into that. Could you check if this is fixed with https://github.com/Zebradil/cloudflare-dynamic-dns/releases/tag/2.5.0 ?

@Zebradil Thanks for looking at this, but it did not work. I ensured I had the EUI-64 address and a privacy address and it kept picking the privacy one. It also didn't print the warning about using an unstable IP address. I tried both the deb and tar.gz binaries from the release page.

@philipl thanks for the quick feedback!
Could you share the IPv6 addresses you deal with (probably change a few last bits to be safe, or send them to github-inbox@zeb.mozmail.com)?
It may be also helpful to run cloudflare-dynamic-dns with --log-level=debug.

Thanks. I emailed you the logs.

Hi @philipl, thank you for the logs. The IPs helped a lot. There was an error in the EUI-64 detection code. Let's see if it is fixed in https://github.com/Zebradil/cloudflare-dynamic-dns/releases/tag/2.6.1

Thanks! Amusingly, I've just replaced my home router and it's refusing to do stateless autoconfig and forcing stateful dhcpv6 so I can't actually test this right now. I've got to fix the router first. sigh

And I managed to fix it. After that I can confirm it's picking the EUI-64 address. Thanks!

Awesome! Thanks for the help with testing and debugging.


lib: defer collecting streams when ack'ing empty frames

When processing ACK frames, quiche collects streams if the conditions
are suitable. Previously, endpoints exchanging 0-length STREAM frames
could confuse things, causing the stream to be collected while still
readable(). Applications that attempted to call stream_recv() would
encounter a InvalidStreamState error.
This change adds a check for is_readable() to the ACK processing, and
a test case to demonstrate the sequence of events that previously
triggered the error.

@LPardue thanks a lot!


Support request about content length

Expected Behaviour
when POSTing a request to a cloud funtion, the request body should be available inside the cloud function. Specifically, the header for content-length should be set and the data should be readable.
We should expect, for example,
curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"a":"1","b":"2"}' \
http://localhost:31112/function/py2fn.openfaas-fn

to respond with:
{"function": "ok", "params": {"a": "1", "b": "2"} }

Current Behaviour
Currently the response is missing the body completely. When I check content length it is not > 0, hence the result:
{"function": "ok", "params": {} }

area of interest: https://github.com/pyramation/python-template-openfaas-of-watchdog-issue/blob/master/template/python3/index.py#L31-L34
Steps to Reproduce (for bugs)

pull the template

faas-cli template pull https://github.com/pyramation/python-template-openfaas-of-watchdog-issue

create a new functions

faas-cli new --lang python2.7 py2fn
faas-cli new --lang python3 py3fn

build and deploy

Since the functions are just passing through params, we can build and deploy them immediately:
export OPENFAAS_URL=localhost:31112
faas build -f ./py2fn.yml
faas build -f ./py3fn.yml
faas deploy -f ./py2fn.yml
faas deploy -f ./py3fn.yml

make requests and see both have same result

curl --header "Content-Type: application/json"   --request POST   --data '{"a":"1","b":"2"}' http://localhost:31112/function/py2fn.openfaas-fn
> {"function": "ok", "params": {} }

curl --header "Content-Type: application/json"   --request POST   --data '{"a":"1","b":"2"}' http://localhost:31112/function/py3fn.openfaas-fn
> {"function": "ok", "params": {} }

verify that it works locally, with proper responses

For python 2.7
cd ./build/py2fn
touch function/__init__.py && PORT=10101 python index.py

# now on another shell...
curl --header "Content-Type: application/json"   --request POST   --data '{"a":"1","b":"2"}' http://localhost:10101
> {"function": "ok", "params": {"a": "1", "b": "2"}}

For python 3
cd ./build/py3fn
touch function/__init__.py && PORT=10101 python3 index.py

# now on another shell...
curl --header "Content-Type: application/json"   --request POST   --data '{"a":"1","b":"2"}' http://localhost:10101
> {"function": "ok", "params": {"a": "1", "b": "2"}}

Context
Trying to create languages for of-watchdog, so I can manipulate headers and create a connector that I'm working on in postgres. Currently nodejs works, so I'm a bit baffled by this body parsing issue.
Your Environment

Docker version 19.03.12
FaaS-netes
MacOS
https://github.com/pyramation/python-template-openfaas-of-watchdog-issue

Can I ask why you need the content length and how you are using it? You're seeing -1 due to a chunked HTTP request, where the data is streamed so no length is available

/set title: Support request about content length

I'm using a built-in python3 library, http.server. All of my research leads to similar methods that read content-length header to parse the body of the request.
After reading this, I started to research into chunked encoding, but I'm not sure if http.server can do it. Did you mention there is a way to tell the system to use content-length?

Thanks again! I think I'm just gonna use the flask template for now, seems light weight enough! Thanks for the info, I'm happy to understand the inter-workings and now accept that I should just use a system that abstracts the chucked/content-length


How to manage subscription key and knowledgebase id in web.config?

The way that QnAMakerServiceAttribute works means this isn't intuitive, as you must use constant expressions for the keys.

Ah ok. Just set the properties in the constructor, like so ...
public QnADialog()
{
    EndpointKey = ConfigurationManager.AppSettings["QnASubscriptionKey"];
    KnowledgeBaseId = ConfigurationManager.AppSettings["QnAKnowledgebaseId"];
    BaseUri = ConfigurationManager.AppSettings["QnAMakerEndPointHostName"];
}


Translate the setup section to French

Hi, just signed the CLA

/approve

/hold
until everyone reviews

/approve
Great job !

/hold cancel

/lgtm


[Event Request] Table 5718 Nonstock Item "OnNonStockItemUnitOfMeasure"

Can we please get the following event?
 field(6; "Unit of Measure"; Code[10])
        {
            Caption = 'Unit of Measure';
            TableRelation = "Unit of Measure";

            trigger OnValidate()
            Var
                IsHandled: Boolean;
            begin
                if ("Unit of Measure" <> xRec."Unit of Measure") and
                   ("Item No." <> '')
                then begin
                     //Event Request begin
                    IsHandled := false;
                    OnNonStockItemUnitOfMeasure(NonStockItem, IsHandled);
                    if not IsHandled then
                    //Event Request end
                        Error(Text001);

                end;
            end;
        }

[IntegrationEvent(false, false)]
 local procedure OnNonStockItemUnitOfMeasure(var NonstockItem: Record "Nonstock Item"; var IsHandled: Boolean)
 begin

 end;

Hi,
Can you please update on the above Event Request. #17621
Thanks,
Dgoyal.

Hi,
Request you to please give an update on the below Event Request. https://github.com/microsoft/ALAppExtensions/issues/17621
Thanks,
Dgoyal.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: .


libmediainfo: 23.11 -> 24.01

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/libmediainfo/versions.
meta.description for libmediainfo is: Shared library for mediainfo
meta.homepage for libmediainfo is: https://mediaarea.net/
meta.changelog for libmediainfo is: https://mediaarea.net/MediaInfo/ChangeLog
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 24.01 with grep in /nix/store/ddfm66yp2mv0b26zxrrdbh7w8vn9hj9n-libmediainfo-24.01
found 24.01 in filename of file in /nix/store/ddfm66yp2mv0b26zxrrdbh7w8vn9hj9n-libmediainfo-24.01

Rebuild report (if merged into master) (click to expand)

30 total rebuild path(s)

30 package rebuild(s)

First fifty rebuilds by attrpath
CuboCore.coreinfo
aaxtomp3
deepin.dde-file-manager
deepin.dde-gsettings-schemas
deepin.deepin-camera
deepin.deepin-screen-recorder
deepin.image-editor
deepin.util-dfm
filebot
libmediainfo
libsForQt5.kdenlive
lidarr
mediaelch
mediaelch-qt5
mediaelch-qt6
mediainfo
mediainfo-gui
megacmd
megasync
plasma5Packages.kdenlive
prowlarr
python311Packages.pymediainfo
python312Packages.pymediainfo
radarr
rapid-photo-downloader
readarr
sonarr
svp
ultrastar-manager
ums

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ddfm66yp2mv0b26zxrrdbh7w8vn9hj9n-libmediainfo-24.01 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libmediainfo https://github.com/r-ryantm/nixpkgs/archive/a2e0285cde305610cdaa96053961fd7a5f5e1912.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/a2e0285cde305610cdaa96053961fd7a5f5e1912#libmediainfo

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ddfm66yp2mv0b26zxrrdbh7w8vn9hj9n-libmediainfo-24.01
ls -la /nix/store/ddfm66yp2mv0b26zxrrdbh7w8vn9hj9n-libmediainfo-24.01/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package marked as broken and skipped:

ultrastar-manager

27 packages built:

CuboCore.coreinfo
aaxtomp3
deepin.dde-file-manager
deepin.dde-gsettings-schemas
deepin.deepin-camera
deepin.deepin-screen-recorder
deepin.image-editor
deepin.util-dfm
filebot
libmediainfo
libsForQt5.kdenlive
lidarr
mediaelch
mediaelch-qt6
mediainfo
mediainfo-gui
megacmd
megasync
prowlarr
python311Packages.pymediainfo
python312Packages.pymediainfo
radarr
rapid-photo-downloader
readarr
sonarr
svp
ums

Maintainer pings
cc @devhell for testing.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1498


Adding components to collections

There does not seem to be a function to add ComponentDefinitions to collections. I was able to create new collections using doc.collections.create() but could not interact with the new collections in any way. I was also hoping for clarification on the addCollection() function as the input required is an sbol object so it cannot be used to create a new collection, but if this is the intended way to add components to existing collections, it lacks a way to specify which collection the sbol objects should be added to.
I would highly appreciate clarification on how these functions are supposed to be used and how I can add components to collections without running into uniqueness errors, because the components are already part of the document.

This example code hopefully shows what I am trying to achieve and what I mean. Adding the component using addCollection only adds it to the general document and not the collection specifically as can be seen in the resulting SBOL file.
doc = Document()
GFP = ComponentDefinition("GFP")
collection = doc.collections.create("collection")
doc.addCollection(GFP)
doc.write("Test_Collections.xml")

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:sbol="http://sbols.org/v2#">
<sbol:Collection rdf:about="http://examples.org/collection/1">
<sbol:persistentIdentity rdf:resource="http://examples.org/collection"/>
sbol:version1</sbol:version>
sbol:displayIdcollection</sbol:displayId>
</sbol:Collection>
<sbol:ComponentDefinition rdf:about="http://examples.org/GFP/1">
<sbol:type rdf:resource="http://www.biopax.org/release/biopax-level3.owl#DnaRegion"/>
sbol:version1</sbol:version>
<sbol:persistentIdentity rdf:resource="http://examples.org/GFP"/>
sbol:displayIdGFP</sbol:displayId>
</sbol:ComponentDefinition>
</rdf:RDF>

Here is a tweaked version of your program:
import sbol2

doc = sbol2.Document()
GFP = sbol2.ComponentDefinition("GFP")
doc.add(GFP)
collection = doc.collections.create("collection")
collection.members = [GFP.identity]
doc.write("Test_Collections.xml")

That program produces the following result:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:sbol="http://sbols.org/v2#">
  <sbol:ComponentDefinition rdf:about="http://examples.org/ComponentDefinition/GFP/1">
    <sbol:type rdf:resource="http://www.biopax.org/release/biopax-level3.owl#DnaRegion"/>
    <sbol:displayId>GFP</sbol:displayId>
    <sbol:version>1</sbol:version>
    <sbol:persistentIdentity rdf:resource="http://examples.org/ComponentDefinition/GFP"/>
  </sbol:ComponentDefinition>
  <sbol:Collection rdf:about="http://examples.org/Collection/collection/1">
    <sbol:version>1</sbol:version>
    <sbol:persistentIdentity rdf:resource="http://examples.org/Collection/collection"/>
    <sbol:member rdf:resource="http://examples.org/ComponentDefinition/GFP/1"/>
    <sbol:displayId>collection</sbol:displayId>
  </sbol:Collection>
</rdf:RDF>

I figured out that I had to use the members property on the Collection by looking at the SBOL 2.3 specification. A Collection has a single property, called members, that refers to TopLevel entities.
There is no error checking here, and the implementation is possibly incorrect because it accepts any URI instead of constraining to URI's of other objects in a document, or even URIs that refer to TopLevel objects. And note that I had to add the ComponentDefinition to the Document separately. I guess my summary is: use with care.
Document.addCollection is a synonym for Document.add and is intended to add a Collection object to a Document. It is not intended to add an entity to a Collection, as you have already discovered. As a synonym, no error checking is done on the passed argument. The Document.addCollection exists for backward compatibility with pySBOL.

And thanks very much for the sample program and output. It was very helpful in formulating my answer.

@tcmitchell Thank you for your answer, this is exactly what I was looking for. I had looked at the members property before, but couldn't quite figure it out.


Improve SEO attribution by replacing iframed wordpress content on /blog with statically generated html blog files

This PR replaces iframed wordpress blog content with static html files of the same content, and introduces a github submodule reference to the static blog files. Along with workflow actions to support automatically updating the *.html files which are included in public/blog.
Benefits of this approach:

Attributes search engine indexing results from blogs to near.org, rather than to pages.near.org
Allows us the ability to improve the blog UX by ensuring that link clicks open in the same window and do not lose the top level navigation options.

Current problems with this PR:

Prevent links from opening in a new tab requires a wordpress admin to change wordpress configs such that each link default to opening in the same browser window/tab
I would've preferred to include public/blog in .gitignore, but due to the href issue in #1, I've copied all blog/*/index.html files into public (that's why this PR has 2K files) and have attempted to update all links to include target=_self.  I'm on the fence as to whether this UX improvement is worth including all these files  (which will auto update on the next static export of wordpress content, as per this config)

1. fix all Tags, "Blog", "Back to All Posts" links
	 public/blog/: href=/blog/>
	replace with: href=/blog target=_self />

2. fix remaining blog links
	search public/blog/: href=/blog/
	replace with: target=_self href=/blog/

3. fix pagination links
        search public/blog/:  " href=/blog?paged="
        replace with: "target=_self href=/blog/page/"

Thanks for taking this on @charleslavon! I'm a little hesitant to merge this due to the massive bloat of public/blog. Are we able to wait until the WordPress admin is able to update the links? Or maybe we can live with the links opening new tabs for the short term?
I wonder if we could somehow create a new layout (extending DefaultLayout) for wrapping these generated HTML pages that listens for all clicks on<a> elements and calls preventDefault() and then uses router.push() in certain cases to get around this link issue.

Thanks for taking this on @charleslavon! I'm a little hesitant to merge this due to the massive bloat of public/blog. Are we able to wait until the WordPress admin is able to update the links? Or maybe we can live with the links opening new tabs for the short term?
I wonder if we could somehow create a new layout (extending DefaultLayout) for wrapping these generated HTML pages that listens for all clicks on<a> elements and calls preventDefault() and then uses router.push() in certain cases to get around this link issue.

hey @calebjacob I've set the majority of those links to open in the current tab via the manual search and replaces that I noted in the description. The last couple of commits have fixed the tags and pagination links.   There is no one actively maintaining this wordpress site anymore, so we can't expect anyone to update/improve those links from within WP.
This public/blog bloat is technical debt that we can remove (and redirect to other pages) In time as this legacy content becomes older.

@charleslavon I might be missing something, but I was doing some testing and am a bit confused.

If you visit here and click on any of the blog links/posts, it still opens a new tab: https://near-discovery-git-removewpblogs-near-developer-console.vercel.app/blog
When you do visit a post, our main navigation is missing: https://near-discovery-git-removewpblogs-near-developer-console.vercel.app/blog/nears-road-to-decentralization-empowering-the-guild-community

You're right. Only the Featured Post, and Back to All Posts links will open in the current tab. The others will open in a new tab (as they currently do). So besides those two UX improvements, the primary benefit of this PR is the SEO attribution and removal of some iframed pages.


Any help on a dependencies issue, please..?

Hi, I'm trying to install mokio following guidelines posted here but unsuccessful. The new_app got created (it seems OK) but got into a dependencies conflict after adding, as instructed, gem 'mokio' in the gemfile. I also tried $ bundle update as the output itself suggests but not success.
I'd appreciate any help.
$ bundle install
Fetching gem metadata from https://rubygems.org/...........
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
Resolving dependencies....
Bundler could not find compatible versions for gem "jquery-rails":
  In snapshot (Gemfile.lock):
    jquery-rails (= 4.2.2)

  In Gemfile:
    jquery-rails

    mokio was resolved to 0.0.5, which depends on
      jquery-rails (>= 3.1.0, ~> 3.1)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

Hi,
sure I'll try to help. First of all, which version of Rails do you want to use? I see that bundle resolves mokio to 0.0.5 which is very old. Currently on rubygems there is 0.0.14 version compatible with Rails 4.1.1 and Ruby 2.1.2, so first maybe try set in your Gemfile the latest version of Mokio. However you can also use Mokio with brand new Rails 5. Take a look into this branch rails5.0. You can use it in your Gemfile as following:
gem "mokio", '0.0.14',:github => 'versoft/mokio', :branch => 'rails5.0'
But there are some issues with that vesion. On the day this branch was released, there wasn't proper version of simple_form gem, so we're using this gem instead:
gem 'simple_form', github: 'kesha-antonov/simple_form', branch: 'rails-5-0', but I think that original simple_form is now compatible with Rails 5, so check it out.
Second issue is about no longer supported gem youtube_it. We also use some fork to get mokio work:
gem 'youtube_it', github: 'LiveWorld/youtube_it'
I hope that above informations will help you.
Take care!

Hi, thanks.
I tried the option gem "mokio", '0.0.14',:github => 'versoft/mokio', :branch => 'rails5.0' and after sorting out some, fortunately,  no difficult to resolve dependence issues (like installing rmagick) the output I got when run the command rake mokio:install is shown below:
$ rake mokio:install
rake aborted!
Gem::LoadError: You have already activated rake 12.0.0, but your Gemfile requires rake 10.5.0.

Hi,
The bundle install performs ok? Maybe try bundle exec rake mokio:install or remove all versions of rake from your gemset and run bundle install again.


[Feature Request]: Multiple PrintNode keys

Feature Description
Is there any way to handle multiple printnode keys in order to manage multiple printnode subscriptions ?
Is this feature valuable for other users as well and why?
No response

You may switch them out at runtime like this:
app(\Rawilk\Printing\Api\PrintNode\PrintNode::class)->setApiKey('your-new-key');

Many thanks for your quick feedback. I will give it a try!


Rework, refactor, revamp

Details
Rework the current web-ui using vue with typescript, vue-pinia for state management. Changes are based on spotdl CLI dev branch.
To-do

[x] Refactor to typescript
[ ] Additional settings capabilities

[ ] Upload custom config file

[x] Frontend
[ ] Backend

[ ] Bitrate

[x] Frontend
[ ] Backend

[ ] Providers as list instead of single select

[x] Frontend
[ ] Backend

[ ] Use YTM data

[x] Frontend
[ ] Backend

[ ] Only verified results

[ ] Frontend
[ ] Backend

[ ] Generate lyrics

[x] Frontend
[ ] Backend

[ ] Threads

[ ] Frontend
[ ] Backend

[ ] Force update metadata

[ ] Frontend
[ ] Backend

[ ] yt-dlp args

[ ] Frontend
[ ] Backend

[ ] ffmpeg args

[ ] Frontend
[ ] Backend

[ ] Output dir

[ ] Frontend
[ ] Backend

[ ] File format

[x] Frontend
[ ] Backend

[ ] Revamp UI
[ ] Check for CLI, and web-ui updates
[ ] Download songs automatically instead of going to downloads and clicking download again #1864
[x] Display search, search results, queue in one page Canceled. Use vue-router instead
[x] Themes & theme changer (daisyui)

[x] Forest
[x] Light
[x] Dark
[x] Cyberpunk
[x] Cupcake

[ ] Miscs

[x]  Footer

[x] New issue link
[x] Docs link

Why and Motivation
My friends and I love to use spotDL. But using the web-ui feels like a bit "outdated", and we encountered some issues using it:

When IDM is active, clicking download on downloads page passes the file to IDM, then the page reloads, shutting down the server. The same behavior with manually entering the http://.../download url in the browser is causing the server to shutdown as it returns { details: "not found" }. I guess it's normal on SPA apps as the server only has / route.

We noticed that web-ui repo is frequently inactive, so we've tried to work on our own version of it.

Please feel free to add some features you'd like to be implemented, on the todos list.

Additional settings capabilities

Settings should be generated automatically based on the settings model since they change quite often.

Additional settings capabilities

Settings should be generated automatically based on the settings model since they change quite often.

Im thinking of just getting the settings on the api/options_model so the web-ui stays updated with the CLI.

Will open a new PR from fresh fork.


Clarification Needed on Dataset Processing

Hi， @M0hammadL， @b-schubert， @ArcaneEmergence， @irene-bonapa and @drEast
I am currently working to reproduce your meaningful study, "Multi-modal generative modeling for joint analysis of single-cell T cell receptor and gene expression data." However, I have encountered some issues while processing the datasets and would greatly appreciate your guidance.

Regarding the Borcherding Dataset
I recently downloaded the Utility v0.0.4 dataset from Zenodo, but I couldn’t locate the rna_combined.h5ad and tcrs_combined.csv files mentioned in preprocessing/Borcherding_preprocessing.ipynb.

When exploring the dataset:
The h5ad files in utility/data/processedData/individualSeurat/h5ad/ contain only gene expression (GEX) information.
The TCR annotations in utility/data/processedData/combinedDataSets/ use barcodes (e.g., barcode) that do not match those in the h5ad objects (e.g., BCT1.1_AAACCTGCAGATCGGA-1).
Could you clarify where to find the paired h5ad and TCR annotation files?

Regarding the COVID Dataset
I downloaded the dataset from GSE171037, but encountered similar issues:

The file GSE171037_TcellReversePT_integrated_Tcells.h5ad only contains GEX data.
The raw data in GSE171037_RAW includes only orphan TCR information (e.g., 'orphan VDJ', 'orphan VJ') without paired TCR data.
Additionally, I couldn’t find the Covid19_TAs_PBMCs.h5ad file mentioned in your work.
Could you please provide guidance on where to find the complete datasets or suggest an alternative approach?
Thank you very much for your time and assistance.

Dear Nicole,
Thanks for your interest in our study.
Unfortunately, we faced a bit of a reproducibility issue here.
For uTILity: We downloaded the data when it was still unversionized. Back then, I downloaded the data from a Google Drive folder (which does not exist anymore) linked in the repository and converted it myself from Seurat to h5ad.
I see two options here:

You process the current version of uTILity to the data format outlined in the tutorials and re-use mvTCR on the new data. The results however will not be comparable, as uTILity has increased since then.
We kindly ask Nick Borcherding whether I can share the data with you over a dropbox. The current license does not allow for derivatives as far as I see. So I would need Nick's OK on this one. Let me know if I should contact him.

For Covid:
Please try the file "GSE171037_TcellReversePT_munich.h5ad". I double-checked, it has all the cells in it that we used in our tests. The Chicago cohort did not have any TCR information, so this information was removed from the joint data object as well as from mvTCR.
I hope that helps. Please let me know if there is anything else.
Best,
Felix

Dear Felix,
Thank you for your detailed explanation and guidance regarding the data reproducibility issues. I truly appreciate your efforts in clarifying the situation.
I have already contacted Nick Borcherding for assistance regarding the Utility v0.0.4 dataset from Zenodo.
Would it be possible to share the data with me via a link? My email address is<EMAIL_ADDRESS>I understand the licensing constraints and would be happy to seek Nick Borcherding's approval if necessary.
Looking forward to your response. Please let me know if there's anything else I can do to facilitate this process.
Best regards,
Nicole


Cleanup csi volume attachments

When deleting a node, ensure all volume attachments have been deleted prior to deleting the node and terminating it.

Put attachment delete, etcd delete, node delete into retry loop

This prevents a PVC from being attached to another node, because the csi controller still thinks it is attached.
To replicate delete a vm, without first deleting it from k8s.


Example 3 is wrong

It claims to generate a default namespace and root tag, but the code produces a root tag with a namespace.  It's a duplicate of Example 4.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 525bf456-96f9-3ec5-baa7-231213dff194
Version Independent ID: e34d6fbd-8233-edcc-d253-def34d2c324f
Content: How to create a document with namespaces (C#) (LINQ to XML)
Content Source: docs/csharp/programming-guide/concepts/linq/how-to-create-a-document-with-namespaces-linq-to-xml.md
Product: dotnet-csharp
Technology: csharp-linq
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Thanks for writing this up @DarinFlippo
I've added it to our backlog, to address when we next update this article.


Journal as sub-pool

The Zed lake design doc speaks of this concept that's not yet implemented:

...the log represents the definitive record of a pool's present and historical content, and accessing its complete detail can provide insights about data layout, provenance, history, and so forth. Thus, Zed lake provides a means to query a pool's entire journal in all its detail. To do so, simply query a pool's journal by referring to the special sub-pool name <pool>:journal.
For example, to aggregate a count of each journal entry type of the pool called logs, you can simply say:
zed lake query "from logs:journal | count() by typeof(this)"

@mccanne's recent thoughts on when we should take this up:

we shouldn’t need this for a while as this is only needed at truly massive cloud scale.
We might want to put thought into it sooner rather than later because we need an API endpoint to scan the log optionally with a Zed query so clients can do intelligent orchestration even before we get to scale.  This may or may not be the current list endpoint.

Note to self: When this gets implemented, update the Zed lake design doc to remove the reference to this being an open isssue.

I can see this is a duplicate of new issue #4114 which includes more text from the now-retired design doc, so I've copied the quote above to #4114 and am closing this one.


array-sum (without recursion)

This is a trick I came up with while solving this problem...

That's both, scary and smart. 😆

Thanks @oniani.


Improvement for k8s.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/

It would be pretty cool to have the diagrams from the introductory page on the same page as the hands-on tutorial itself so I have something to refer back to and connect with the steps in the tutorial 😄

/kind feature
/priority backlog
/language en
(and then copy this to the other localizations downstream once merged)
@dcaponi do you think you could sketch how you'd like this to look? (“No” or “Not really” is a valid answer! - but if you can, that would help make sure we're clear on a way forward)

/kind feature
/priority backlog
/language en
(and then copy this to the other localizations downstream once merged)
@dcaponi do you think you could sketch how you'd like this to look? (“No” or “Not really” is a valid answer! - but if you can, that would help make sure we're clear on a way forward)


Fix/datetime format

Adding the filelock strategy seems to solve the issue when both rs-server-adgs and rs-server-cadip  want to create the same table. I tested, not more errors. For me, this can be merged


fix(query-core): Show correct placeholderData when reuest in cache

Fixes #6341
The issue was the logic to set the lastQueryWithDefinedData was one level lower than expected so the branch was never executed for previous requests existing in the cache. I have included the test case and it works as expected now

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Files
Coverage Δ

packages/query-core/src/queryObserver.ts
83.16% <100.00%> (ø)

... and 12 files with indirect coverage changes
:loudspeaker: Thoughts on this report? Let us know!