feat: add test spec

- I envision that the spec tests can only test a tree:Node (basic elements of the Tree), or a part of the full tree graph, therefore I made these two categories in the conformance points.
- The tests, in my view, need to emphasize the minimum requirements of a TREE implementation (the content of the TREE).
- I included the generated HTML in the PR as well. Please feel free to comment on the current version. I would like to collect feedback on the current format and will remove the HTML once the PR is settled.

Author: xdxxxdx

04-tests.bs

@@ -11,57 +11,116 @@ Mailing List Archives: https://lists.w3.org/Archives/Public/public-treecg/
 Editor:
   - Pieter Colpaert, https://pietercolpaert.be
   - Xueying Deng, https://xdxxxdx.github.io/
-Abstract: The TREE test specification aims to provide enough resource that for a TREE implementation to be able to test itself against the TREE specification.This test specification will be continuously updated to align with changes and improvements in the TREE specification.
+Abstract: The TREE test specification aims to provide resource that for a TREE implementation to be able to test itself against the TREE specification.This test specification will be continuously updated to align with changes and improvements in the TREE specification.
 </pre>
 # Overview # {#overview}
 
 The TREE specification follows the [RFC 2119](https://www.rfc-editor.org/rfc2119.txt) norms for defining conformance requirements. 
-This document lists all conformance points from the TREE specification, and provides corresponding test cases, test environments, and expected results for implementations.
+This document outlines the minimum conformance requirements from the TREE specification and provides corresponding test cases to verify the compliance.
 <!-- (#ToBeDecided) The test specification focuses on TREE client behaviors. -->
 
-## Conformance ## {#conformance}
+# Conformance Points # {#conformance-points}
 
 The conformance points in this document are based on the [TREE specification](https://w3c.github.io/treecg/specification/) and are intended for testing implementations of the TREE specification.  
 
-As TREE is based on hypermedia, the conformance is designed for HTTP-based implementation, the test cases are designed to be executed over HTTP(s), and the expected results are based on the HTTP(s) responses.
+TREE conformance is designed for HTTP-based implementations; all test cases are expected to be executed over HTTP(s), and results are determined from the HTTP(s) responses. Since TREE is an RDF (Resource Description Framework) specification, all response payloads must use standard RDF serialization formats, such as Turtle, RDF/XML, or JSON-LD.
 
-Conformance points are divided into two categories: **MUST** and **SHOULD**.
 
-Each conformance point is described in detail, including the expected behavior of the implementation. The test cases used to verify compliance are also provided.
+<!-- (#ToBeDecided) Maybe we should only keep must? to keep minimum implementation requirements -->
 
-- **MUST** conformance points are mandatory for all implementations. Implementations that do not meet these requirements are not considered compliant with the specification.
-- **SHOULD** conformance points are optional but recommended. Implementations that do not meet these requirements may still be considered compliant, but may not provide the same level of functionality or interoperability.
+<!-- (#ToBeDecided) The conformance of the TREE contains only two parts, the basic elements of a single nodes, and how these nodes are linked (search tree) -->
 
-<!-- (#ToBeDecided) Maybe we should only keep must? to keep minimum implementation requirements -->
-## MUST Conformance Points## {#must}
+## TREE basic elements ## {#1.1}
+
+### Subject of `tree:view` must be a `tree:Collection` ### {#1.1.1}
+**Description:** When there is a `tree:view` in the payload of the current HTTP(s) response, the subject of the `tree:view` must be a `tree:Collection`
+
+**SHACL shape against the HTTP(s) response:** 
+```turtle
+@prefix sh: <http://www.w3.org/ns/shacl#> .
+@prefix tree: <https://w3id.org/tree#> .
 
-### TREE basic elements ### {#1.1}
+tree:ViewSubjectConstraintShape
+    a sh:NodeShape ;
+    sh:targetSubjectsOf tree:view ;
+    sh:class tree:Collection ;
+    sh:message "Subject of tree:view must be a tree:Collection" .
 
-- When there is a `tree:view` in the payload of the current HTTP response, the subject of the `tree:view` must be a `tree:Collection`
+```
+### Subject of `tree:member` must be either a `tree:Collection` or a `tree:RootNode` ### {#1.1.2}
+**Description:** If a `tree:member` property appears in the payload of the current HTTP(s) response, its subject MUST be either a `tree:Collection` or a `tree:RootNode`.
 
+**SHACL shape against the HTTP(s) response:** 
 ```turtle
 @prefix sh: <http://www.w3.org/ns/shacl#> .
 @prefix tree: <https://w3id.org/tree#> .
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
 
-# SHACL Node Shape to validate that any subject having tree:view must be a tree:Collection
+tree:MemberSubjectConstraintShape
+    a sh:NodeShape ;
+    sh:targetSubjectsOf tree:member ;
+    sh:or (
+        [ sh:class tree:Collection ]
+        [ sh:class tree:RootNode ]
+    ) ;
+    sh:message "Subject of tree:member must be either a tree:Collection or a tree:RootNode" .
+
+```
+### `tree:Relation` properties ### {#1.1.3}
+
+**Description:** If a `tree:Relation` appears in the payload of the current HTTP(s) response, it MUST have a `tree:path` property and a `tree:node` property which pointing to another `tree:Node`.  
+    `tree:Relation` is a superclass for all TREE-supported relation types (such as `tree:GreaterThanRelation`, `tree:LessThanRelation`, `tree:GreaterThanOrEqualToRelation`, etc.).  
+    For the complete list of subclasses of `tree:Relation`, see [tree.ttl](https://github.com/TREEcg/specification/blob/master/tree.ttl).
+
+**SHACL shape against the HTTP(s) response:** 
+```turtle
+@prefix sh: <http://www.w3.org/ns/shacl#> .
+@prefix tree: <https://w3id.org/tree#> .
 
-<#TreeViewSubjectMustBeCollectionShape>
+tree:RelationConstraintShape
     a sh:NodeShape ;
-    sh:targetSubjectsOf tree:view ;
+    sh:targetClass tree:Relation ;
+    sh:property [
+        sh:path tree:path ;
+        sh:minCount 1 ;
+        sh:message "tree:Relation must have a tree:path property"
+    ] ;
     sh:property [
-        sh:path rdf:type ;
-        sh:hasValue tree:Collection ;
-        sh:message "Subjects that have a tree:view must be a tree:Collection." ;
+        sh:path tree:node ;
+        sh:minCount 1 ;
+        sh:class tree:Node ;
+        sh:message "tree:Relation must have a tree:node property pointing to a tree:Node"
     ] .
+```
+
+### Initialization of TREE structure via `tree:view` after dereferencing ### {#1.1.4}
+**Description:** When a `tree:view` triple exists in the payload of the final HTTP(s) response (after following all redirects), the final IRI MUST be the object of a `tree:view` triple whose subject is a `tree:Collection`. This ensures that dereferencing a resource leads to a valid TREE view associated with a collection.
+
+**SHACL shape against the HTTP(s) response:**
+
+```turtle
+@prefix sh: <http://www.w3.org/ns/shacl#> .
+@prefix tree: <https://w3id.org/tree#> .
 
+tree:ViewObjectConstraintShape
+    a sh:NodeShape ;
+    sh:targetObjectsOf tree:view ;
+    sh:sparql [
+        sh:select """
+            SELECT $this
+            WHERE {
+                ?collection a tree:Collection .
+                ?collection tree:view $this .
+            }
+        """ ;
+        sh:message "The final IRI must be the object of a tree:view triple whose subject is a tree:Collection"
+    ] .
 ```
-<!-- (#ToBeDecided) host this under tree domain?-->
-- When there is a `tree:member` in the payload of the current HTTP response, the subject of the `tree:member` must be a `tree:Collection` or a `tree:RootNode` 
-- When there is a `tree:Relation` in the payload of the current HTTP response, the subject of the `tree:Relation` must also point to a `tree:path`
+## Search TREE ##  {#1.2}
+
+### `tree:Node` inbound link uniqueness ### {#1.2.1}
+**Description:** During traversal of the TREE structure, each `tree:Node` MUST NOT be the target of more than one inbound `tree:Relation` (i.e., via the `tree:node` property) from a different `tree:Node`. In other words, no `tree:Node` should have more than one parent node. This requirement ensures that the TREE remains a valid tree structure, where each node has at most one parent.
 
-### Search TREE ###  {#1.2}
-- At any point in the TREE, each `tree:Node` may have at most one inbound link via a `tree:Relation` from another `tree:Node`.
+**SHACL shape against the RDF graph:**
 
 ```turtle
 @prefix sh: <http://www.w3.org/ns/shacl#> .
@@ -87,24 +146,18 @@ ex:NodeInboundUniquenessShape
     ] .
 
 ````
-- Whenever `tree:GreaterThanRelation` is used as a comparator within the TREE, the values pointed by `tree:path` in the members MUST be compared using the rules defined in the [SPARQL algebra functions](https://www.w3.org/TR/sparql11-query/#expressions).
-<!-- 
-// ### The member extraction algorithm ### {#1.3}
-// ### Traversing the search tree ### {#1.4}
-// ### Pruning branches ### {#1.5}
+### `tree:GreaterThanRelation` ### {#1.2.2}
+**Description:** When traversing a TREE structure by following `tree:Relation` links (after making one or more HTTP(s) requests and aggregating the resulting RDF graphs), if a `tree:GreaterThanRelation` is present, then for each member referenced by the relation, the value of the property specified by `tree:path` MUST be greater than the value specified in the relation, according to the comparison rules defined in the [SPARQL algebra functions](https://www.w3.org/TR/sparql11-query/#expressions). This ensures that the `tree:GreaterThanRelation` accurately represents a "greater than" relationship as defined by SPARQL semantics.
+
+
+### `xsd:dateTime` literals without a timezone comparisons  ### {#1.2.3}
+**Description:** When traversing a TREE structure, if an implementation employs `xsd:dateTime` literals without an explicit timezone, it MUST treat these values as representing the entire range from that date and time at UTC-14:00 (inclusive) to UTC+14:00 (exclusive). Comparisons involving such `xsd:dateTime` values MUST be performed as interval comparisons: a value without a timezone matches if and only if the comparison holds for at least one instant within this interval. Implementations MUST NOT assume any default timezone or offset for such values.
 
 
-// ## SHOULD Conformance Points## {#must}
 
-// ### Initialization ###  {#2.1}
-// ### The member extraction algorithm ### {#2.2}
-// ### Traversing the search tree ### {#2.3}
-// ### Pruning branches ### {#2.4}
--->
 <!-- 
+// Initial version
 // TODO
-// * SHOULD: The implementation should support this feature.
-
 
 // # Tests # {#tests}