- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 14 Oct 2016 08:33:48 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
- Message-ID: <c7d8964c-1244-56f2-4450-dbecb0c76bee@topquadrant.com>
Understood. But I don't think we are there yet. We could keep the current design and downgrade sh:hasShape to optional if nobody else than me is able to implement it. Holger On 14/10/2016 4:08, Arnaud Le Hors wrote: > Holger Knublauch <holger@topquadrant.com> wrote on 10/13/2016 09:58:21 AM: > > ... > > Making a feature optional basically means it cannot be used > > reliably. We have too many optional features already because there > > is always someone who will be against something, or has a specific > > implementation strategy in mind. Instead of adding further optional > > features, we should go the opposite way. Engines that don't want to > > support these features simply should not be allowed to claim SHACL > > Full compliance, but some smaller dialect. > > ... > > I'm the first one to say that everytime something optional is included > in a standard interoperability suffers so I certainly share your > sentiment on that front but you might want to be careful what you wish > for. Remember that if we can't have at least 2 implementations of > SHACL Full (in our timeframe), we won't be able to exit CR. I have yet > to hear where the second implementation is coming from and making it > harder is most surely not going to help get one. > For it's worth I know of several SHACL Core implementations so at > least we should be able to get that part to REC if we can stabilize > the spec in time. > -- > Arnaud Le Hors - Senior Technical Staff Member, Open Web Technologies > - IBM Cloud > > >
Received on Thursday, 13 October 2016 22:34:21 UTC