[4739] 5.1.3 smlerr output element node serialization

Pratul: Vijay was interested in this. it's already optional; proposal to change from Second Draft o LC.

RESOLUTION: So agreed.

[4774] schema binding

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 on, 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 consumer 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 fails 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 documents.

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. (involving c language specification and schema processor that exposes no psvi properties.)

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/redefine 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.
... but 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].

<scribe> scribe: Valentina

Continue debate on topic 4774 - schema binding issues

<Sandy> http://lists.w3.org/Archives/Public/public-sml/2007Aug/0087.html

start by reviewing section 6.2.4

Pratul: it seems that this is similar with something that is already available in SMLIF

no comments for 6.2.4, moving forward

review section 6.3

Sandy: there are no defaults here, you have to specify everything

Kirk: not sure why the consumer of SMLIF should go through all this validation since the SMLIF schema validation has been done already

MSM: requires associations between the SMLIF instance documents with the schema instances , as the producer had intended to

Kirk: understands the need

moving to section 7.1 - Analysis

7.1 Namespace matching

Pratul: typo in 7.1 first item; If is OK even if B and D should be 'It is OK even if B and D'
... what is the scenario for item 3 ( exchange schema but not use it for validating SMLIF instances )

Sandy: the consumer just needs a new version of a schema to update its schema definition. It is not linked with any SMLIF instance document

John: another scenario: the user is working on some files, they are not yet ready ( not valid ) but you still want to exchange this with the consumer. The producer wants to let the consumer know that they are incomplete documents

Pratul: a third option when exchanging incomplete documents is to not a send the definition document with the incomplete instances

John: there is no implication in the SMLIF spec that instance documents should be used for validation

Pratul: if we go this path we may overcomplicate the scenarios. May probably have next a consumer who wants to send some documents and ask the consumer to only use certain documents

MSM: looking at the spec, it says the producer sends the instances and the definitions to validate this document
... this should not be the only scenario

John: you can do this, the spec doesn't write it specifically this way

Sandy: any more comments on 7.1 ?

Sandy moving to 7.2 - Explicit schema binding

MSM: what do you mean by being more difficult than 7.1 ?

John: computationally is the same, the actual content of the SMLIF differs; this is where the complexity resides

Kumar: is 4.1 satisfied by the explicit schema binding ?

Sandy: you can have 4.1 only when you know that an SMLIF is incomplete; explicit schema binding proposal allows you to do that
... moving to section 8 - Conclusion

MSM: question on the Overview of ‘Explicit schema binding’ approach subsection
... I am assuming this is a cumulative sample; don't understand why I need schema level binding if I have default namespace approach

Valentina: it explains what happens when you have two definition documents using the same namespace while having two instance documents pointing to one/respsctive the other schema. If a global schema binding is used then at least one instance level mapping is required to support this

Pratul: if we don't have this case where you have two schemas with the same namespace ; do you still need the schema binding ?

Sandy: no, you go with the default namespace matching for simple cases
... this is just an illustrative example on how schema binding will be appllied on conflicts

Pratul: assuming we go with this approach, we need to make sure we align with the rule binding approach

Sandy: likely but this is a next step
... comments ?

Partul: let's assume we don't have this duplicate schema scenario. Do we still need schema binding to support the import/include scenarios ?

Sandy: yes, some cases still require specific binding

MSM: can we have a chameleon include sample ?

Pratul: how does schema deal with this situation ?

MSM: schema spec does not define an algorithm for that

<Sandy> e.g. 2 schema docs for the "empty" ns; xsd1 is really for "empty", and xsd2 to be chameleon included. then in schema binding, the global binding will have "empty -> xsd1 (leaving xsd2 out).

MSM: every chameleon is an orphan; is called in using the schema location

Sandy: for redefine, the producer decides what algorithm to use for mapping; can be namespace match which means included in the synthetic schema . Or can use schema binding, in which case it will have to specify the corresponding schema level binding
... commments?

Kumar: overall looks good, it tries to address all issues. Need some more work on a few issues though
... is this a proposal to make this a requirement ?

Sandy: yes; this is how we should guarantee interop

Kumar: in this case I am not comfortable with having to support conflicting schemas. Do we know how many processors support that ?

Sandy: this is not a processor issue; if your app uses a processor that doesn't understand conflicting schema, the app can choose to pass the information the processor can't process

Kumar: not sure how this works

Sandy: for every instance you create different processor instances

Kumar: but I may have dependencies between instances

Sandy: good question; probably need to ask that those documents be compatible relative to the schema

MSM: this come as a comment for the definition of the model validity

John: at least one of the target constraint requires PSVI - I think is the target element

MSM: reading the description of the target type; I don't see a definition of the target type when using multiple documents
... when you cross schema documents
... sample; have one instance using n1:T and n2:e. Other instance uses n1:T and n3:e
... the two instances are compatible since they are using the same n1:T

Pratul: correct, but this results into an identity of the type

MSM: correct

John: think about having two schema documents having the same namespce n1:T
... the only way you get around this is by requiring to use the latest schema defining n1:T
... if you have backward and forward compatibility then this is safe

Valentina: I don't see backw and fwd compatibly as a regular scenario. Most of the time you don't have fwd compatibility

MSM: backf and fwd compatibility can happen when you have a wildcard in the old schema which is more restricted in the new schema
... my point is that fwd and backward compatibily is not impossible but it is not a regular scenario

John: if you have conflicting schema and you are trying to use both you can't

Kumar: if I send SMIF documents and have conflicting data, for consumers to generate the same result we need some information on how to validate

MSM: schema spec doesn't say anything about two type definitions describing the same thing

Pratul: my position is: if there are two conflicting schemas then the SML model should be marked as invalid

MSM: depends on the goal of SML
... in real life is quite usual to use different versions of the same schema
... SML model is essentially a set of xml documents; so some SML models may expect to have this conflicting situations
... trading example: multiple companies are exchanging data
... one company may use different schema for the same namespace as a corporate policy
... ( different from what other company may use for the same namespace )

Marv: we have a similar situation
... have different versions of a model and some divisions use one version, some other divisions use a different one. We want to have this option of choosing what schema version to use

Kumar: but this leads to ambiguity

<pratul> Why can't Marv not use two different namespaces

Marv: but it should be my choice; I want to reduce the requirements that I have to impose on the usage of a certain schema. In the end makes the spec more valuable. If we decide that this is impossible to implement that's fine but I would prefer to be able to make a choice

Pratul: still don't see a clear scenario where conflicting schemas are being used

Marv: use one schema in 2001, two years later a better version of this schema is produced
... in real life, the new schema will be used but the change will not happen everywhere
... now I am using an CMDBf
... I want to be able to use the same namspace for the two versions and recognize that

MSM: XSLT is a schema sample where community didn't want to use different samespaces for new versions
... we need to take into consideration what happens in real life when defining the SMLIF; don't impose a constraint on what data should be in SML model just because we think this is how in the real life it should work

Kumar: conflicting schemas means a processor being required to support different versions of the same schema

John: not in the same session

MSM: the existing of two conflicting schemas should be supported by a processor - have some sort of options on how to solve it, such as telling the processor which schema to use. The validation will not be done in the same session if two conflicting schemas are to be used

Pratul: we don't have a consensus on this

Jim: can this be made implementation specific ?

Pratul: if it's not defined by the interop then in my view it's useless

John: we can split the interop in two parts
... one is what we do now, then a second conformance section which offers more

Jim: some implementations may support some versions of the schema binding but not all the options

Sandy: if you support schema binding then you by definition support all of the proposed options since they produce the end solution

John: so if a producer offers some options to do schema binding some of the consumers may choose not to support ( will ignore ) some of these options
... but in this case the interop will become too complex

Pratul: conclusion on 4774 - schema binding issue - I don't think we have a consensus yet

John: to make progress for the second draft we should continue this discussion by mail

Pratul: propose to discuss 4774 in the next week's call

Kirk: should a separate action be opened to review the need of having conflicting schemas?

Pratul: it is already captured in 4774 proposal so for now let's keep it there
... let's try to have the schema binding issue solved for the second draft so that we can have the schema group review the proposal

Kumar: what else should be discussed since it seems we covered everything ?

Pratul: have no consensus yet; there are members of the group who were not part of this discussion

Reference proposal

<MSM> http://lists.w3.org/Archives/Public/public-sml/2007Aug/att-0086/SML_References.html

<MSM> http://lists.w3.org/Archives/Public/public-sml/2007Aug/0086.html

Sandy: Section 1

Kumar: is this consistent with what is already in the spec?

John: SML spec has two ways of recognizing sml references
... this definition covers both cases and adds now ones
... current schema definition says that ref can be recognized at the schema level only by extending the refType

Section 2 - How are reference elements handled?

MSM: what means mainline ?

Sandy: how you handle references in deref functions

John: the content of an sml:uri can be a reference. In order to test for the reference, you need to call the deref.
... you can replace mainline with the implementation of every reference scheme the consumer recognizes

Sandy: moving to the list under 'The general form for handling non-null references is shown below.'

Kumar: should we have in 2.1 a case where none of them resolve ?

Sandy: yes, we need this

Pratul: why 2.1 ? ( a consumer MUST attempt the validation .. )
... it feels that the validator is forced to do all options

John: your processor recognizes only some schemes

Sandy: validators are special case of consumers

Kumar: in 2.2, the consumer is required to validate at least one ?

MSM: if I support a scheme, am I required to validate it ?

John: good question

Pratul: if we have section 2.2 we allow to have two things in the spec: one which is the validator and the other which is a consumer

Sandy: to answer MSM question : if you recognize a scheme but you didn't try to validate any of them, then is in violation with 2.2.3

MSM: 2.2.3 talks about a slightly different thing

Sandy: not decided yet but personally don't care if you didn't try any of the schemes even if you recognize some

MSM: this should be a design discussion
... we should come back to this design discussion

<MSM> specific design question to come back to: do we want to allow / prohibit super-lazy consumers? good-faith consumers? Does a consumer have to try until either something succeeds or until there are no further schemes to try?

John: re differences between validators and consumers : for validator we want to impose rules so that you have a common result

<MSM> As drafted, this seems to allow consumers to decline to try any of the schemes they support, and treat all references as unresolved.

John: probably don't want to impose the same things for consumers

Kumar; it seems that there are 3 types of consumers: validators, consumers, any

John: consumers obey rule 2.2; validators obey rule 2.1

<pratul> Why should SML spec care about any other consumers except validators?

MSM: The description on non-validators in 2.2 doesn't seem to address the case that one of the ref scheme resolve to multiple elements

Sandy: 2.2 is the opposite to 2.1

MSM: second quest: I am assuming that 2.1.3 has as a consequence that if I validate right now everything is fine; if I plug out the network, ( after it checks first scheme and before the next ) I get validation errors

Sandy: it is a case not covered

Ginny: with 2.1 two consumers can get two different results

John: that's right, but we are on a different case here

MSM: yes, schema validator can give different results in the network unplugged scenario but in this case we don't get different results, we get back errors

Sandy: but schema connectivty affects the SML model

MSM: that's true if the definition of the model depends on what's reachable

Pratul: discuss identity of elements, all related to section 2.1.2

MSM: document identity is subject to negotiations; yes, we need to specify what we understand by object identity

Ginny: same comment as Pratul related to what an object identity refers to

<MSM> [if we make explicit that these descriptions of the validation process assume / rely on the assumption that all documents in the model are reachable, then item 2.1.3 is not problematic, MSM thinks]

Kirk: how do you know that you may get multiple references if deref always returns one element ( this is related to summary item 'If a scheme or multiple schemes resolve to more than one target, make R unresolved.')

Sandy: in this case you should not use the deref implementation

Kumar: we should differentiate between multiple targets and no target
... both seems to map to unresolved

MSM: we need to make a better system of errors ( what fells under unresolved, as opposed to could not be reached because of network failure, etc )

Sandy: I don't think this only applies to this issue; the error system should be used in other places in the SML spec

John: the agreement seems to be that we need to create this separate set of errors

Sandy: we need to come up with a proposal for the text on how to handle all this cases

Kumar: how do we interpret 2.2.3 ?

MSM: question on how to read 2.1.1, 2.1.2, 2.3; all seems to return errors; are these really errors or unresolved, etc. We need to set on terminology

John: one approach is to take these 'errors' as needing refinement on whether this should be not known or errors
... I am comfortable as looking at this proposal and reading the term 'error' as 'not known' or errors. The fundamentals are correct

<scribe> ACTION: Sandy to refine this proposal to deal with document not reachable due to network issues [recorded in http://www.w3.org/2007/08/29-sml-minutes.html#action01]

<trackbot-ng> Created ACTION-120 - Refine proposal on Reference Proposal to deal with document not reachable due to network issues [on Sandy Gao - due 2007-09-05].

Ginny: can you provide a back-up scheme for the case when first scheme is not reachable over the network ?

MSM: do we have agreement that the consumers should try at least one of the schemes ?

<MSM> JA: no, the SML semantics a consumer implements may not require any dereferencing of refs at all. MSM: right, I'm persuaded.

John: we asked whether we should require non-validating consumers to try at least one scheme they recognize. The decision is that this is too strong requirement

one example is one consumer who recognizes only SML references by using sml:ref

<MSM> [N.B. the final para of section 2 speaks of "an error for cases described in 2.3" -- typo for 2.1, or 2.2, or 2.*.3 ...]

MSM: what is a unit in 'Rationale: it's a unit, because we should not constrain how schemes are defined. '

John: it says that if someone defines a scheme to allow multiple reference types, it should describe what this means and how a validator should use this data
... unit = within the same reference you have more than one schemes. That reference is referred to as a unit

Pratul: should we allow a reference having two schemes of the same type ?

John: we should discuss this and understand what to enforce at the schema spec level

Kumar: question about the rationale of dangling ref
... I see a reference to a model boundary

Sandy: you cannot tell if the reference doesn't exist or cannot be accessed; that's why it was decided to remove the dangling notion and use only unresolved

break for lunch

 

 

Continuation of discussion  of Sandy's recommendation regarding SML references

http://lists.w3.org/Archives/Public/public-sml/2007Aug/att-0086/SML_References.html

Section 3

How are schemes defined?

Jim: Opened new bug to clarify Identity issue. 4992

John: This probably will not be 2nd draft

Pratul: Questions whether this is a topic required for the spec. John &MSM: Yes

<scribe:> Bug has yet to be triaged. Not assigned to draft.

MSM: Overlapping schemes. Foo scheme (have only foo occurrence) vs. foo-bar scheme, the latter saying you can have two foo schemes. An occurrence of one foo scheme can be taken as either one or both.
...Problem occurs when there are two instance and validator says this is not good because it's not foo. This is unacceptable.
...Consequence of first bullet: you MAY not get satisfactory validation.

<pratul> In this case, the definition of foo scheme can also specify how it can be reused without causing the probelm
...So in Michael's case the definition of the foo-bar scheme is broken
...since it violates the definition of foo scheme

MSM: Validator doesn't know what scheme the occurrence is supposed to be a instance of.
...So validation is undercut, since there might be another scheme that makes it valid.

Ginny: Is there a reason to allow overlapping schemes?

John: Not allowing overlap seems to be going too far in restricting freedom of definition (e.g., requiring container elements)

Jim: Doesn't spec say scheme element must be child?

MSM: We have an issue against this. It is a restriction that limits schemes--eliminates attribute schemes.

MSM: Validation should assume you know what scheme you want to use.
...This situation is like saying, here is a well-formed XML doc, is it valid? Depends upon what schema you use.
...You effect this with outside information. If you want to use an overlapping scheme, that's your maintenance problem.

<Kirk> General idea: there needs to be a hook to tell validator what schemes to use.

<pratul> There was no formal consensus on the "Validator Hook" issue

Kumar: Case of validator that understands uri-scheme and gets 2-uri schemes, which is not instance of SML uri.

John: Sandy's version: reference contains exactly 1 one sml URI tag (example of SML URI ref scheme)
...Kumar's proposal: If reference contains 1 or more <sml:uri> tag (and it is an example of SML URI ref scheme)
...if = 1 tag, then resolve
...else ERROR

John: Part of validation process, telling validator what schemes to validate. If different schemes, you will get different behavior.

Ginny: Can there be differences in how validators handle overlapping schemes?

John: Scheme definitions include specification of how to recognize scheme. Therefore, this is not a prolem.

Pratul: Scheme definitions are a specification on a piece of paper given to programmer.

Ginny: How can you tell if only one instance of tag in Kumar's example?

Sandy: This situation is an instance of both schemes.

Ginny: Example: Have three uri tags: one uri in one scheme, two others in the other?

<MSM > if you have a scheme that says "if you see two uri tags, choose one of them and dereference it", i.e. if you have a non-deterministic scheme, then shall we outlaw that? Answer: no need to outlaw it. "Your gun, your bullet, your foot."

Sandy: We are taking the entire reference element to try against all your reference rules. (Order does not matter.)

John: We need to either anticipate conflicts of schemes or down stream we must be able to tell validator how to resolve conflicting sets.

Ginny: We need "cautionary notes" in the spec.

Jim: We should not allow the case in which we cannot tell the difference. Not allow case in which your validator cannot uniquely determine which scheme applies.

<pratul> I agree with Ginny re the "cautionary Note"

Kumar: I think we are taking on complexity to define corner cases. (Probably unnecessary.)
..."complexity" = facing situation of not being able to tell or resolve overlapping scheme

MSM: Nothing can prevent overlapping scheme (2 schemes with same tag). We get simplicity in the spec by saying you need to recognize the scheme. If you use overlapping schemes, it is not our responsibility to prevent people from getting into these problems we've been discussing.

<scribe> What Kumar called complexity, Sandy sees as simplicity.
...Kumar: Complexity as applied to implementors.

Jim: We need to "absolve" implementators of need to disambiguating situation in which they can't tell which scheme is being used.

<Sandy> The "xinclude" case is also interesting. It uses attributes.

John: We can recommend what to do; instead of complete "absolution".

MSM: We'll need to set options on validators to turn on and off schemes it knows about.

John: Proposal to refine this email
...Make recommendation against overlapping schemes, but since we can't prevent it from occurring, it needs to be addressed.

Sandy: XInclude: uses an attribute-based scheme. Attributes can overlap with other specs.
...The element itself is the reference vs. our sub-element approach.

<scribe> How this works: Given an occurrence of scheme, the definition of a scheme does tell you whether that instance is an instance of this scheme or not. A reference is unresolved only if the instance is evaluated against all schemes and it fits none of them

MSM: Make it more explicit to explain that a scheme that requires 3 uris and gets 6 and says, yes, this is an instance of my scheme; then it is up to the definition of scheme how to dereference the case in which 6 uris are provided.
...This is an editorial change that should be made.

Final decision: Section 3 needs refinement based on this discussion.

Section 4

Pratul: Second paragraph accords with teleconf. decision. Proposal: To close 4884.

John: Do we have semantic agreement (over syntax agreement)?

<scribe> Consensus: We need a notion of a null reference

<scribe> Discussion of use of null reference to represent "This course doesn't have an assistant teacher". MSM: Ok with this.

<scribe> Consensus: We agree on the semantics of the solution.

John: Does anyone dissagree with sml:nilref at this time?

<scribe> All: no objection to this name at this time.

Pratul: We also have consensus in 4780/4795. Is this correct?

<scribe> Resolution: targetRequired constraint requires that the reference be resolvable, be within the model, and be non-null.
...Consensus: .We are getting rid of concept of "empty".
...Correct 4780: remove references to "empty" and "dangling".

Sandy: Opening issue for removing "empty" and "dangling" references.

BREAK

Section 5

Pratul: Agrees with option 2.

MSM: We can retrofit existing vocabularies. What was value of requiring value being fixed? Instance level cannot distinguish between references and non-reference use.

John: Use of GUI tools. No value in saying type level MAY be a reference.
...Also, fixed is useful for static analysis.

MSM: What depends on calling a type a reference?
....Response: use of constraints: Acyclic, TargetXXX are defined only for references.

MSM: Fixed is too restrictive for retrofiting existing vocabularies. But MSM needs to think through issues of static analysis and constraints.

MSM/Pratul: Only enforce constraints if instance is sml:ref="true". Otherwise, treat instance as null reference.
...Cannot check constraint (presence of out-going arc) because it may be a null reference or a scheme you do not understand

MSM: Fixed="true" doesn't buy you anything.

MSM: Discussion of arcs needs to be clarified for null references.

Jim: Section also implies that the instance is the arc. This needs to be clarified.

MSM: Constraints are enforceable only if reference is NOT nil, so fixed="true" does not buy you anything.

TargetRequired issue

Pratul: Define it to say that we can choose to define targetXXX constraints as enforced only on instances for which sml:ref="true" if we decide that sml:ref is an optional attribute for reference types

John: Value of not having fixed="true" (going from MUST to MAY) is able to have new references for existing vocabulary and still preserve original vocabulary.

MSM: Fixed="true" does not buy you anything for the GUI.

Sandy: Only issue in our specs is, Where do we put the constraint attributes? Allowed only where fixed="true".

MSM: Concepts in existing vocabulary may not map into SML semantics of reference. Fixed="true" made this impossible. We could not represent reference semantics in existing vocabularies.
...We cannot map from a more precise vocabulary (subset or overlapping set) to a general vocabulary without the loss of semantics. Fixed="true" makes it impossible to do the mapping.
...This is an example of the problem of Architectural Forms.

Discussion of the issue. John explains this issue by using multiple inheritance. There is a need to introduce a new type to say that a subset of an original type are sml references if it is done with fixed="true".
..."Price of entry" to make the distinction between ref and non-ref instance of the type: add sml:ref=true. If a new type is must be identified, there are also metadata changes.
...Approach of MSM does not prevent static analysis.
...Some types can fix its value to true, and this supports static analysis. But does not preclude other types for not fixing value to true.

MSM: On what types can we impose the contraints?
 ...some types always have sml:ref="true"
 ...some types May have sml:ref="true"
 ...    some have it explicitly
 ...    some have it by extension wildcard)
 ...some type never have sml:ref="true"

MSM: For the always case: you still have to check for null, not too much more expensive than checking for sml:ref=true.

Kumar: Does loss of significant value in Option 2 mean that we should go to Option 3?

MSM: Possible solution for applying constraints: always and MAY (explicitly)

Kumar: shall we include MAY (wc) as well?

<scribe> Issue: for option 3: where can the constraints be written. Reminder: these are attributes in the schema.

<scribe> We can specify the constraints on any complex type and they have meaning only for those instances with sml:ref="true". If not specified on the complexType, there is nothing to check.
...Constraints apply one to defined complex types with attribute extensibility. Or, the sml:ref="true" as required and fixed="true".

Jim: We might want to add constraints to an abstract or parent type in order to say that all subtypes is acyclic.
...MSM: Great idea!

MSM: All situations for applying constraints (above table) are encomposed by this solution!!

<Sandy> acyclic and targetXXX are allowed in all 5 options:
...1. types derived from refType and elements with those types
...2. types with sml:ref + required + fixed=true
...3. types with explicit reference to sml:ref, allowing either true or false value
...4. types that allow sml:ref attribute, allowing true or false, via wildcard or explicit reference
...5. no restriction. they can be specified on any element or type.
...   any element instance with sml:ref="true"

<scribe: > Consensus in Room: This is agreed upon. sml:RefType is gone. Recognize instances using following rule for Option 5:

<MSM> Option 4:  sml:refType is gone.
...any element instance with sml:ref='true' is an sml reference.
...(already so in part 1 of the working paper)

<MSM> - Q. which type definitions may carry constraints like sml:acyclic?

<MSM> A. Any complex type definition at all. (We CANNOT require that sml:ref
...be allowed explicitly or by wildcard, because of Jim's point.)

<MSM> Those constraints are enforced on the set of instances of that
...type definition which are in fact SML references.

Ginny: This sounds good

<scribe> WE HAVE CONSENSUS!!!

Sandy: Two additional questions
...1. Use key ref but XPath does not point to a key? How does deref work?
...    MSM: handle in deref. An element that is not a reference refers to nothing. Return nothing. (We may want to revisit this with XPath 2)
    We have Consensus on this answer.
...2. Schema has default for sml:ref="true" in the PSVI.
...    Pratul: This is not a reference according to our spec. PSVI is not required.
...    Kumar: But the requirement is not that PSVI should be ignored.
...    MSM: If you use the PSVI and I don't, this is a serious interop problem.
...    Kumar text must say not to look at PSVI.
...    Kumar: problem where sml:ref="True" in a parent type of the subtype of which the instance is an instance.

<Sandy> I understand all the concerns; but there is a nice application.

<Sandy> with support for schema default of sml:ref, then there is no need to change existing documents by adding sml:ref to make them SML documents.

<MSM> Kumar: there is not really an interop problem in allowing the PSVI to be consulted.

<Sandy> E.g. if I have thousands of XInclude documents, I can simply write a schema that provides sml:ref=true to <xinclude> elements and now they are suddenly sml refs, without the need to modify those instance documents.

<MSM> There is no interop problem for sml model validators, because they all must do schema validation

<MSM> Kumar: and the interop problem for non-validating consumers is no bigger than the one we already have thanks to things like scheme support

<Sandy> MSM: should also ignore DTD defaulted sml:ref attributes, because there's no guaranteed interop. some processor may not read attribute decls from external DTDs.

Adjourning: 6:40.

[End of 
    scribe.perl diagnostic output]