SML f2f second day -- 29 Aug 2007

<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 intended

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 need 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 definition files 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 that the producer sends the instances and the definitions to validate this documents
... 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 document 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 stil lneed 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 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 redefin, the producer decides what the algorithm to use for mapping; can be namespace match which means included in the synthetic schema . Or can use the 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 quarantee interop

Kumar: in this case I am not confortable 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 process can process

Kumar: not sure how this worl

Sandy: for every instance 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 nl: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 than 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 division 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 shoudl 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 inthenrop 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 at 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

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

Reference proposal

<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 refence scheme the consumer recognizes

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

Kumar: should we havein 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> ginny, we are dialing in

<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

<sml> 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

<pratul> Sorry, I was earlier logged in as user "sml"

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 refinment on wheter this should be not known or errors
... I am confortable as looking at these proposal and reading the term 'error' as to '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 shold 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

<Kirk> scribe: Kirk

<Kirk> Continuation of topic: How are schemes defined?

<Kirk> Jim: Opened new bug to identify Identity issue. 4992

<Kirk> John: This probably will not be 2nd draft

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

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

<Kirk> MSM: Overlapping schemes. Foo scheme (have only foo occurrence) vs. foo-bar scheme, the latter saying you can have two foo schemes. An occurence of one foo scheme can be taken as either one or both.

<Kirk> ...Problem when two instance and validator says not good because it's not foo. This is unacceptable.

<Kirk> ...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 casuing the probelm

<pratul> So in Michael's case the definition of the foo-bar scheme is broken

<pratul> since it violates the definition of foo scheme

<Kirk> MSM: Validator doesn't know what scheme the occurrence is supposed to be a instance of.

<Kirk> ...So validation is undercut, since there might be another scheme that makes it valid.

<Kirk> Ginny: Is there a reason to allow overlapping schemes?

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

<Kirk> Jim: Doesn't spec say scheme element must be child.

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

<Kirk> MSM: Validation should assume you know what scheme you want to use.

<Kirk> ...This situation is like saying, here is a well-formed XML doc, is it valid? Depends upon what schema you use.

<Kirk> ...MSM: you do this with outside information. If you want to use an overlapping scheme, that's your maintenance problem.

<Kirk> Consensus appears that there needs to be a hook to tell validator what schemes to use.

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

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

<Kirk> John: Sandy's version: reference contains exactly 1 one sml URI tag (example of SML URI ref scheme)

<Kirk> ...Kumar's proposal: If reference contains 1 or more <sml:uri> tag (and it is an example of SML URI ref scheme)

<Kirk> ...if = 1 tag, then resolve

<Kirk> ...else ERROR

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

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

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

<Kirk> NOTE Scheme definitions are a specification on a piece of paper given to programmer.

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

<Kirk> Sandy: This situation is an instance of both schemes.

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

<MSM> 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.

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

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

<Kirk> Ginny: We need "cautionary notes" in the spec.

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

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

<Kirk> Kumar: I think we are taking on complexity to define corner cases. (Probably unnecessary.)

<Kirk> ..."complexity" = facing situation of not being able to tell or overlapping scheme

<Kirk> 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.

<Kirk> Sandy: What Kumar call complexity, Sandy sees this as simplicity. (Kumar: Complexity applies to implementators.)

<Kirk> Jim: We need to "absolve" implementators of need to disambiguating situation in which they can't tell which scheme.

<Sandy> the "xinclude" case is also interesting. it uses attributes.

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

<Kirk> MSM: We'll need to set options on validators to turn on and off schemes it know about.

<Kirk> John: Proposal to refine this email

<Kirk> ...Make recommendation against overlapping scheme, but that we can't be prevented, that it needs to be addressed.

<Kirk> Sandy: XInclude: uses an attribute-based scheme. Attributes can overlap with other spec.s.

<Kirk> ...The element itself is the reference vs. our sub-element approach.

<Kirk> How this works: Given an occurrence of scheme, the definition of a scheme does 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

<Kirk> MSM: Make it more explicit to explain that a scheme that requires 3 uris and gets 6 and says, yes, this is a instance of my scheme; then it is up to the definition of scheme how to dereference the case in which 6 uris are provided.

<Kirk> ...This is an editorial change that should be made.

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

Section 4

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

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

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

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

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

<Kirk> John: Syntax should be discussed in email by tomorrow.

<Kirk> John: Does any dissagree with sml:nilref at this time?

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

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

<Kirk> Resolution will be recorded here: targetRequired will be applied to null references.

<Kirk> .. Consensus: .We are getting rid of concept of "empty".

<Kirk> ...Correct 4780: remove references to "empty" and "dangling".

<Kirk> Sandy: Opening issue one issue for removing "empty" and "dangling" references.

<Kirk> BREAK

Section 5

<Kirk> Pratul: Agrees with option 2.

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

<Kirk> John: Use of GUI tools. No value in saying type level MAY be a reference.

<Kirk> ...Fixed falue is useful for static analysis.

<Kirk> MSM: What depends on calling a type a reference?

<Kirk> ....Response: use of constraints: Acyclic, TargetXXX are defined only for references.

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

<Kirk> MSM/Pratul: only enforce constraints if instance is sml:ref="true". Otherwise, treat instance as null reference.

<Kirk> ...Cannot check constraint (out of going arc) because it may be a null reference or a scheme you do not understand

<Kirk> MSM: Fixed=true doesn't buy you anything.

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

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

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

<Kirk> TargetRequired issue

<Kirk> Pratul: Define it to say that ???

<pratul> We can choose to define targetXXX constrainst as enforced only on instances for which sml:ref="true" if we decide that sml:ref is an optional attribute for reference types

<Kirk> 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.

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

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

<Kirk> 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.

<Kirk> ...We cannot map from a more precise vocabulary (superset or overlapping set) to a general vocabulary without the loss of semantics. Fixed="true" makes it impossible to do the mapping.

<Kirk> ...This is an example of the problem of Architectural Forms.

<Kirk> 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".

<Kirk> ..."Price of entry" to make the distinguish 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.

<Kirk> ...Approach of MSM does not prevent static analysis.

<Kirk> ...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.

<Kirk> MSM: On what types can we impose the contraints?

<Kirk> ....some types always have sml:ref="true"

<Kirk> ...some type never have sml:ref="true"

<Kirk> ...some types May have sml:ref="true"

<Kirk> ... some have it explicitly

<Kirk> ... some have it by extension wildcard)

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

<Kirk> Kumar: Does sufficient value in Option 2 that we should go to Option 3?

<Kirk> We can keep sml:refType to get the fixed value and apply constraints.

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

<Kirk> ...Kumar's question: include MAY (wc) as well.

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

<Kirk> 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.

<Kirk> ...Constraints apply one to defined complex types with attribute extensibility. Or, the sml:ref="true" as required and fixed="true".

<Kirk> 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!

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

<Sandy> acyclic and targetXXX are only allowed in (5 options):

<Sandy> 1. types derived from refType and elements with those types

<Sandy> 2. types with sml:ref + required + fixed=true

<Sandy> 3. types with explicit reference to sml:ref, allowing either true or false value

<Sandy> 4. types that allow sml:ref attribute, allowing true or false, via wildcard or explicit reference

<Kirk> Consensus in Room: This is agreed upon. sml:RefType is gone. Recognize instances using following rule:

<Sandy> 5. no restriction. they can be specified on any element or type.

<Kirk> ...any element instance with sml:ref="true"

<Kirk> ...Wjem cam S<: ref Cpmstraomts be s[ecofeod

<MSM> Option 4:

<MSM> - sml:refType is gone.

<MSM> - any element instance with sml:ref='true' is an sml reference.

<MSM> (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

<MSM> be allowed explicitly or by wildcard, because of Jim's point.)

<MSM> Those constraints are enforced on the set of instances of that

<MSM> type definition which are in fact SML references.

<Kirk> Ginny: This sounds good

<Kirk> WE HAVE CONSENSUS!!!

<ginny> /msg MSM thank you!

<Kirk> Sandy: Two additional questions

<Kirk> ...1. Use key ref but XPath does not point to a key? How does deref work?

<Kirk> ... 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)

<Kirk> ... We have Consensus on this answer.

<Kirk> ...2. Schema has default for sml:ref="true" in the PVSI.

<Kirk> ... Pratul: This is not a reference according to our spec. PSVI is not required.

<Kirk> ... Kumar: But the requirement is not that PVSI should be ignored.

<Kirk> ... MSM: If you use the PSVI and I don't, this is a serious interop problem.

<Kirk> ... Kumar text must say not to look at PSVI.

<Kirk> ... Kumar: problem where sml:ref="True" in a parent type of the subtype of which the instance is an instance.

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

<Sandy> 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> 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

<Kirk> Adjourning: 6:40

<ginny> /quit

<Jim> d

<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.

- DRAFT -

SML f2f second day

29 Aug 2007

Attendees

Contents

Continue debate on topic 4774 - schema binding issues

Reference proposal

Section 4

Section 5

Summary of Action Items

Scribe.perl diagnostic output