This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Implementation of references that target non-root elements is challenging for persistent SML stores built on top of relational database systems. The standards body to which SML gets submitted should investigate this and, if needed, explore options to ease the implementation burden for persistent SML stores using relational databases. Possible areas of investigation are Restricting the XPath expression in XPointer fragment (similar to XPath expressions allowed in xs:selector) Defining a new scheme for URIs that contain XPointer fragment
*** Bug 4826 has been marked as a duplicate of this bug. ***
The title is somewhat misleading. It should read: support for references pointing to elements other than root elements should be optional This is because, in a large scale store it is extremely hard to provide reasonable performance when an implementation must support references pointing to elements other than root elements.
*** Bug 4941 has been marked as a duplicate of this bug. ***
Proposal: Support for references pointing to elements other than root elements should be optional. Reasons: 1. In a large scale SML store, if references are allowed to point to elements other than the root element of a document, the size of the ref table becomes an order of magnitude larger than the size of the document table. This introduces perf problems that are hard to overcome. a. Ref targets must be identified by their xpath. This can be a very long string which makes it expensive/inefficient to index on it. b. If a document is updated, all incoming and outgoing references must be rechecked to verify that the at-most-one-target rule is not violated. This is expensive when there are a large number of documents in the store. It harms insert performance. c. Checking target* constraints requires that the entire SML document be indexed. This is very expensive. 2. If references can only target the root of a document, the above problems go away. a. Ref target can simply be a document-id which can be an int. Indexing on this is a lot more efficient compared to indexing on an unlimited length string. b. If document is updated, we do not need to check any ref to see if the at-most-one-target rule is violated since there can only be 1 root element. Thus, that rule is never violated. c. It is far more efficient to store the type/element info of a root element of a document than it is to store that info for all elements in the document. This means that we do not need to index the entire document for the purpose of checking target* constraints. This provides a significant perf boost on insert.
Per Action 130, the following is a proposal for rewording the SML spec. (This bug does not address the SML-IF spec and, therefore, neither does the following proposal.) ================= There 2 issues for the sml spec per our meeting conversation. 1. Does the definition of a reference, as stated, require support for access to non-root elements? 2. Are user-defined reference schemes required to support "fragment identifies", i.e., access to non-root elements? The answer to both questions is "no" but some feel the spec is not clear enough on this. PROPOSAL: 1. Change definition of reference (4.1, para. 3) FROM: An SML reference is a link from one element in an SML model to another element from the same model. It can be represented by using a variety of schemes, such as 4.2.1 URI Scheme and Endpoint References (EPRs) [WS-Addressing Core]. SML does not mandate the use of any specific scheme for representing references; implementations are free to choose suitable schemes for representing references. References MUST be supported by model validators that conform to this specification. An SML reference MAY use one or more reference schemes. TO: An SML reference is a link from one element in an SML model to another element in the same model. SML references can be represented by using a variety of schemes, such as 4.2.1 URI Scheme and Endpoint References (EPRs) [WS-Addressing Core]. It is not required that all elements in an SML model be reachable via an SML reference. This will depend on the capabilities of the chosen reference scheme. SML does not mandate the use of any specific scheme for representing references; implementations are free to choose suitable schemes for representing references. However, references MUST be supported by model validators that conform to this specification. An SML reference MAY use one or more reference schemes. 2. Change definition of reference scheme (4.2, para. 1) FROM: A reference MAY be represented by using a variety of schemes, and SML does not mandate the use of any specific schemes. A reference scheme normally uses, but is not required to use, child elements, attributes or both to capture the information necessary to identify a resource. 4.2.1 URI Scheme and endpoint references (EPRs) [WS-Addressing Core] are two common schemes for referencing resources. Although SML does not require the use of either scheme, it does define how a reference MUST be represented using the URI scheme and the EPR scheme. TO: An SML reference MUST be represented by at least one reference scheme. An SML reference MAY be represented by multiple schemes. SML does not mandate the use of any specific reference scheme. A reference scheme MUST resolve to an element in the SML model but support for non-root elements is OPTIONAL. In order to capture the information necessary to identify the targeted element, a reference scheme MAY use, but is not required to use, the following: - child elements or attributes, or both. - a fragment identifier, or other semantically similar construct, that enables the reference to resolve to a non-root element of an instance document. The URI Scheme and endpoint references (EPRs) [WS-Addressing Core] are two common schemes for referencing resources. Although SML does not require the use of either scheme, it does define how a reference MUST be represented when using the URI scheme or the EPR scheme.
Resolution: Update spec as in comment #5. Also, we are not making the change as proposed in comment #2. Also, correct the title of this bug.
Correction to previous comment: I "corrected" the title.
Section 4.3 Reference Schemes updated on first paragraph from An SML reference MAY be represented by using a variety of schemes, including those defined in this specification. SML does not mandate the use of any specific schemes. A reference scheme MAY use child elements, attributes, both, or neither to capture the information necessary to identify the reference target. [..] to ( added last 2 sentences ) An SML reference MAY be represented by using a variety of schemes, including those defined in this specification. SML does not mandate the use of any specific schemes. A reference scheme MAY use child elements, attributes, both, or neither to capture the information necessary to identify the reference target. It is not required that all elements in an SML model be reachable via an SML reference. This will depend on the support defined by the chosen reference scheme. [..]
I agree with the change in comment# 8