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 terminorlogies to describe "xml schema valid" which is not a defined term in the SML Schema spec.
<MSM> http://www.w3.org/XML/2001/06/validity-outcomes.html has an overview that may be useful here.
<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 SML Schema documents and Instnace 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, validatin must be possible"
<Jim> changed to validation assessment.
<Jim> Wordsmithing to be dnoe by editors.
<scribe> scribe: Sandy
<scribe> scribenick: Sandy
Pratul: Vijay was interested in this. it's already optional; proposal to change from Second Draft o LC.
RESOLUTION: So agreed.
Background information: http://lists.w3.org/Archives/Public/public-sml/2007Aug/0053.html
Valentina's proposal: http://lists.w3.org/Archives/Public/public-sml/2007Aug/0087.html
Kirk: in section 2, may help if
more explicit connection was made between the 3 bullets and the
conclusion.
... section 3: breaking changes allowed in newer versions using
the same namespace?
SG/MSM: yes, up to the schema author.
Pratul: section 3.2: why need different schemas from different versions in the same IF?
MSM: imagine I have loose-html schema and strict-html schema.
Pratul: how is it handled now by schema?
MSM: that's why schema allows many resolution strategies. the entity who asks for validation selects which schema to use.
Pratul: why the same namespace?
MSM: for XHTML, it originally had
3 namespaces. turned out to be a disaster and had to change to
using 1 namespace.
... question about 4.1. maybe IF should be self-complete. that
is, all schema documents are always included.
John: later one, we suggest that we define an inter-op case. which is only guaranteed if all schema docs are included.
Pratul: 4.3 disagree, may have to update instance docs in smlif instance eg to translate scheme contents.
John: true that some impls do this, but does not have to be true in general. this section was really pointing out that we cannot control whether or not the model def documents make use of xs:include, import, redefine, and whether or not schema location is coded on them.'
MSM: lazy schema assembly is a strange thing to have here.
Kumar: if you add a new schema to an SML model, which already has a conflicting schema, what happens?
MSM: that depends on your product. database systems exhibit different behaviors. some tolerate multiple schema with same namespace; some don't.
Ginny: the incomplete set: the IF may be complete leaving the producer; it may then be changed by the comsumer to be incomplete.
<ginny> A producer can create a complete set but if the consumer does reference a schema outside the set
<MSM> [In the current prose, the definition of completeness seems to depend on schema processor policy for acquiring components; in that case, the sender's processor and the receiver's processor might provide different answers. But I assume that's a glitch of some kind.]
John: open question: whether we need an explicit assert by the producer about whether the IF is in the complete set.
<ginny> I would say if the SML-IF instance can be processed/validated without referencing a non-included schema, then it is complete -- regardless of what the consumer does about referencing schemas.
MSM: 2 possibilities. 1 is to
define a policy; after applying it a consumer still needs to
load docs outside of IF, then it's incomplete.
... 2 is define closure of include/redefine/import to determine
whether it's complete.
... we don't want as a goal is to make it possible to use
existing schema processors to be used as-is.
<MSM> [other things being equal, allowing the use of off the shelf processors would be good -- but I don't think we want to reject anything that failes to allow it.]
John: It is necessary for a producer to declaratively distinguish between these two cases, since it is not always possible to distinguish based on the content alone. For example, XML Schema allows xs:include��s schema location attribute��s value to not resolve, although the value is required. This can be done by introducing a ��complete�� attribute on the <smlif:definitions> element to indicate whether this SML-IF instance includes all necessary definition docume
When this attribute is specified with an actual value ��true��, then for the instance to be valid, its schema definition documents and instance documents can only refer to either built-in components or components from definition documents included in the instance.
Ginny: if producer produces "complete" IF; it should have all schema binding specified to achive interop (e.g. use binding in preference over schema locations)
Sandy: yes. when "complete" is true, a policy must be enforced by consumers to guarantee inter-op. even when "complete" is not true, we may still want to require the same binding rule. (e.g. use schema docs in IF before seeking out)
MSM: question about "complete". if i have 3 elements A, B, C; i have components for A and B, but not for C. can i mark this IF complete?
Sandy: yes. and it implies that the consumer is not allowed to look for a schema doc outside the IF for C.
Kumar: schema allows different behavior in terms of schema composition; why does SML need to define a specific approach?
John: xml schema is a general purpose language; sml-if needs to guarantee interop.
Kumar: i want to use existing schema processors.
MSM: argument and analogy that we can't and shouldn't expect that *any* conforming schema processor can be used as-is in sml validator. (involing c language specification and schema processor that exposes no psvi properties.)
<MSM> /me admires Sandy's concise summary of a long and wandering rant
John: this is specifically about interchange. need to make sure different consumers process IF instances in the same way.
MSM: for a schema processor that ignores schema locations but takes a list of schema documents to build a schema, then i can use it to implement the "synthetic" schema approach desribed in the proposal.
Kirk: 3rd paragraph in 6.1 "... with schema locations pointing to schema documents from the namespace-to-schema-document mapping."
Prutal: 4th paragraph in 6.1. required to attempt to resolve <include/redefine>. what happens if if fails?
MSM: not an error. you must try,
but ok if it fails.
... about 6.2.2, consistency question. imagine schema doc S has
def-level ns1->T; T has def-level ns2->S1 (same tns as
S). OK?
Sandy: the idea is to load both S and S1 (trust everybody); conflicts result in errors.
Ginny: need aliases for include/redeine etc. as well as schema binding.
MSM: observes that we can ignore
include schemaLocation, or always point to the root document
for that namespace.
... this avoids honoring schemaLocation.
Sandy: redefine can't be handled using this strategy; so we might as well handle include and redefine in the same way.
John: last paragraph of 6.2.3, does it apply to all schema binding options?
Valentina/Sandy: yes
Kumar: for "explicit binding", do we *always* need a catalog specified in the IF?
Valentina: not always. if the default (namespace matching) works, then no explicit override is needed.
Kumar: how does the producer know which schema documents should be used to validate each instance, so it can calculate the set of bindings necessary?
Valentina: producer has knowledge of data
Kumar: it's the conflicting case
where this gets interesting
... when the model inst doc using one version of a schema doc
for which other versions exist in the store, did part of the
"add new MID" process specify which schema doc of the two
should be used?
Pratul: shouldn't this be specified in SML, and not SML-IF?
Sandy: the reason it's here is
because IF needs guaranteed interop, so we not only need to
require processors to conform to schema, but also specify
additional rules to achive interop.
... buf for SML, schema processors can do whatever they want;
and schema already handles this case (multiple versions in same
model).
Pratul: we need to answer first whether we allow conflicting schema docs in the same SML model. if not, then this can be greatly simplified.
MSM: similar question. should SML/SML-IF allow conflicting schema docs?
John: need to put different CMDBs in the same SML model; each CMDB may have its own schemas.
Pratul: if the new version doesn't breaking existing instance, should be ok to keep only one version.
MSM: hard to maintain both
backward and forward compatibility
... what does SML currently say. is conflicting schema docs
supposed to be supported?
Sandy: I think yes. SML is any set of XML documents; and schema knows how to handle multiple-version-same-ns.
MSM: producer supports conflicting schema docs; send it in IF, to a consumer that doesn't support it, the consumer can't correctly understand the IF. a problem?
John: no. the same as IF having reference schemes not recognized by the consumer. no guarantee that all consumers can understand everything in an IF instance.
Kumar: in an SML model, there is a schema doc and many instances; later on, a conflicting schema doc is added. what happens?
Pratul: no defined in our specs. up to your processor.
John: possible options: reject, keep both, replace, treat as an instance doc, ... bottom line: anything; SML doesn't specify it.
Kumar: are we required to support it (conflicting schema docs)?
Sandy: as an SML processor and producer, you are not required to support it. But as a consumer, if an IF contains conflicting schema docs, you need to understand. but it's up to you what to do with it. e.g. you may choose to only store one schema in the model and ignore the other(s).
Pratul: or we can, in SML-IF, to say if a consumer doesn't support it, then it can ignore additional versions in the IF.
Kumar/Pratul: back to the question of whether we need to support this in SML at all.
Sandy: we had the CMDB case John mentioned earlier. And given we are making SML a general purpose validation language, we need to consider other cases. from my experience, WPS and SDO need the capability to handle multiple versions of the same schema at the same time.
John: eclipse tools, validation is explicit UI action, not done automatically all the time. then it's possible to have half-ready schemas.
<scribe> ACTION: Sandy to provide more detailed scenario description about handling multiple versions at the same time. [recorded in http://www.w3.org/2007/08/28-sml-minutes.html#action03]
<trackbot-ng> Created ACTION-119 - Provide more detailed scenario description about handling multiple versions at the same time. [on Sandy Gao - due 2007-09-04].
<Valentina> 230 Commerce Valley Dr E
<Valentina> Bombay Bhel
<Valentina> we are here : L6G 1C7
<ginny> /leave Bye, everyone! Enjoy the dinner! :-)
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/stricly/strictly/ Succeeded: s/attribut/attribute/ Succeeded: s/ht euse/the use/ Found Scribe: Sandy Inferring ScribeNick: Sandy Found ScribeNick: Sandy Default Present: Paul, Marv, Kirk, Kumar, MSM, Pratul, Jim, Valentina, Sandy, Ginny Present: Paul Marv Kirk Kumar MSM Pratul Jim Valentina Sandy Ginny John Regrets: Zulah Got date from IRC log name: 28 Aug 2007 Guessing minutes URL: http://www.w3.org/2007/08/28-sml-minutes.html People with action items: kirk sandy valentina[End of scribe.perl diagnostic output]