See also: IRC log
<Jim> Kumar requests that persistent stores be exempt from implementing identity constraints on deref () function.
<Jim> Kumar suggests allowing deref() in the selector but not in the field expression.
<MSM> Several aspects of the current design cause problems, says Kumar:
<MSM> - fan-out of search space caused by multiple derefs()
<MSM> - task of crossing the wall between the application and the SQL server (if multiple derefs were in the same query, the server could deal with them -- it's passing the interim result back and then getting new queries on the results that kills you)
<MSM> - strictly speaking, naive implementation does not incur an implementation burden -- just a performance burden. Trying to get performance to be acceptable, though, is an implementation burden.
<MSM> SG points out that the fan-out must happen only by one document having multiple references: the field expression cannot point to more than one result, so it cannot contribute to fan-out.
<MSM> Kumar: consider two cases: (a) has two-level deref in selector, none in the field. (b) has one level in the selector and one in the field.
<MSM> In case (a), if each level has a 1:1000 fanout, you get a million results from SQL in a single query.
<MSM> In case (b), you get the same million results, but it takes 1001 queries.
<MSM> And then, if the environment is highly concurrent, you end up needing locks on everything.
<Jim> Decision to move Bug 4657 to Last Call.
<Jim> Kumar to update the bug with technical details from our discussion.
<Jim> Bug 4658
Sandy's email http://lists.w3.org/Archives/Public/public-sml/2007Aug/0086.html
which covers 4658, 4673, 4682, 4683, 4780/4795, 4834, 4865, 4884, 4976
<Jim> Bug 4676
<Jim> Pratul proposed that since documentURI is optional, as is the locator element, we leave this as it is.
<Jim> Agreed to close this bug.
<Jim> Sandy to open bug to address interoperable way of defining locators.
<Jim> Bug 4684
Kirk's email on 4684 http://lists.w3.org/Archives/Public/public-sml/2007Aug/0080.html
<Jim> Kirk pointed out that this idea was not as simple to implement as it first seemed.
<Jim> The goal is to build SML models from existing documents.
<Jim> The question was raised as to whether sml:keyref should restrict the scope of keys to the subtree whose ancestor is shared by its keyref.
<Jim> ACTION: Kirk to research further and follow up via email towards resolution on this Bug. [recorded in http://www.w3.org/2007/08/28-sml-minutes.html#action01]
<trackbot-ng> Created ACTION-117 - Research further and follow up via email towards resolution on this Bug. [on Kirk Wilson - due 2007-09-04].
<Jim> Kumar raised the issue that using keys and keyrefs in different documents is problematic because we are referencing one symbol from another symbol space.
<Jim> Sandy suggests that we make the spec clear on this point once we decide - Sandy will open a new bug on this.
<Jim> Both 4684 and the new one is moved to Last Call.
<Jim> ACTION: Valentina to explore implementation of deref() in XPath [recorded in http://www.w3.org/2007/08/28-sml-minutes.html#action02]
<trackbot-ng> Created ACTION-118 - Explore implementation of deref() in XPath [on Valentina Popescu - due 2007-09-04].
<MSM> http://www.w3.org/XML/2001/06/validity-outcomes.html has an overview that may be useful here.
<Jim> Bug 4686 Use schema terminologies to describe "xml schema valid" which is not a defined term in the SML Schema spec.
<Jim> MSM differntiated between the notion of conformance in XML Schema 1.0 vs. 1.1 as follows:
<Jim> 1.0 does not define the term "conformance" for documents.
<Jim> 1.1 defines the "conformance" for XML Schema documents and Instance documents.
<MSM> no, not for instance documents. Instance documents do not conform, or fail to conform, to XSDL.
<Jim> John proposed that we agree at an abstract level what we mean by "validity" to accomodate the second draft as it is to be reviewed by the SML Schema WG.
<Jim> We can revisit as needed based on feedback from implementors.
<Jim> Kumar requested that a note be added to the spec to emphaize that this is not a final definition.
<my:root xmlns:...> -- valid
<my:ref sml:ref="true"> -- valid
<sml:uri>...</sml:uri> -- valid
<some:element> -- notKnown
<child xsi:type="xs:int>abc</child> -- invalid
</some:element>
</my:ref>
</my:root>
<Jim> Sandy made three proposals:
<Jim> 1. That PSVI properties be exposed and available for use to the users/consumers.
<Jim> 2. That we define our criteria for the boolean value of validity.
<Jim> 3. That the notion of valid vs. invalid does not require any specific behavior by the validator or the process that invokes it.
<Jim> MSM proposed that we require that no element or attribute is invalid anywhere in the tree.
<Jim> Proposal to add the constraint that the root element of each document must be valid.
<Jim> Vote showed majority for this Proposal.
<Jim> This change will be made to the 4th bullet in section 6.
<MSM> proposal for second bullet: editors to clarify that this means "xs:schema element in each schema document has [validity] = 'valid'"
<MSM> SG alternative for second bullet: schema document must give rise to a conforming schema (this is a stronger constraint)
<Jim> Sandy raised the case where a schema document is not valid and therefore cannot be used to validate an instance document.
<Jim> Pratul proposed that for bullet 4, we should say something such as:
<Jim> "For each document, validation must be possible"
<Jim> changed to validation assessment.
<Jim> Wordsmithing to be dnoe by editors.