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]