See also: IRC log
agenda at http://lists.w3.org/Archives/Public/public-sml/2007Dec/0107.html
<scribe> scribe: Kirk Wilson
<scribe> scribeNick: Kirk
MSM regrets:24-31
Valentina regrets: 24-31
Ginny regrets: 17 and 24-31
John raises question of whether we should have calls next week. Pratul to look at minutes
Minutes not yet distributed or people did not have time to review.
No new action items or bugs.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4772
John: Any objection through comment #6?
No objections.
MSM has submitted editorial clarifications, comment #9.
Resolution: No objection to moving these changes to editorial. Editors should look at comment #9.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4992
Ginny: Sandy has comments in Comment #20. Mostly editorial changes.
John: Any objection to accepting
comment #20 as editorial
... Accept comments in #19 and #20.
Resolution: Move 4992 to Editorial and accept changes in #19 & 20.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5291
Ginny: Recommends not backing out any of the changes and notes that Kirk recommended a rephrasing of a sentence.
John: Proposal is to accept comment #10 and moved to editorial
Resolution: This is editorial and not needsReview and make change in comment #10.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5294
Resolution: 5294 is Resolved.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5301
Resolution: Resolved
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5318
Resolution: Resolved.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4644
Sandy's and Kumar's comments. Kumar advises that there are a large number of changes.
Ginny: Did review but did not go into it deeply.
Resolution: Up through comment #5, we will accept. If new issues, there should be new issues opened.
John: Any objection to making comment #6 editorial.
Kumar: is Ok with making it editorial but will discuss with Sandy.
Resolution: 4644 is editorial.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5247
Kumar put in text several days ago.
MSM: Ambiguity in the phrase "not part of interchange set".
Sandy: either it is there or it is not.
MSM: Simpler to require data to have a child and base64 data be non-empty.
John: We need to allow for tombstone documents. If change prevents this, then it will undo other issue resolutions.
MSM: Agrees
Resolution: 5247 is Fixed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4636
Kumar: This is just editing some of the words.
Resolution: Fixed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774
Ginny: Suggesting we can step through Sandy's comments in #17.
John: Inside 17, from comment 9, point 2 (17.9.2): rewording regarding schema incomplete ambiguity.
Ginny: This is confusing
Sandy: SchemaComplete should mean "known to be complete".
Kirk: The naming of the attribute may help to resolve ambiguity.
John: We can resolve after LC.
<johnarwe> ...the part in comment 12 where a rename of the syntax is suggested, not the whole thing, can be done after LC
Ginny:Name is OK, if we define precisely. We should change definition to reflect Sandy's intention.
<MSM> [I wonder if the description could be "The SML-IF document is not known to be schema-complete".
Resolution: Accept rewording as
suggested by Sandy in 17.9.2. Move to Editorial
Turning to comment 17.9.3
Resolution: 17.9.3 is editorial
Point 12 in comment 9 in 17
John: Any objecdtion to adding wildcard spec to namespace binding type.
Resolution: No objection. Editorial
Point 15 in comment 9 in 17
Proposal: Have a default="false" for schemaComplete attribute
Pratul: Most common case will be schemaComplete="true".
Sandy explains rationale behind default for schemaComplete="false"
Pratul: Agree
MSM: Status quo treats it as false; but it doesn't address Pratul's suggestion that this is behavior we want to promote.
Pratul: Withdraws objection.
MSM: Thinks it is better if there were default="true" or make attribute required.
Ginny: Support required and no default attribute
MSM: If default is true, then any incompleteness will be flagged during validation.
<zulah> I prefer default="true"
Kumar:I support required and no default.
Proposal: adding default and
making value 'False"
... Objections from MSM and Zulah
Proposal: adding default and
making value "True"
...Ginny and Kirk object
Kumar does not object but prefers third proposal
Proposal: make schemaComplete
required and no default value
...No objections
Resolution: 17.9.15: Make attribute Required with no default value.
<johnarwe> proposed change: steps 6 and 7 are applied in current draft only if schemabindings element is used. should also apply if no such element is present or if the consumer does not support schema bindings
Point 1 in comment 14 in 17
Comment 17.14.1: Schema location--when looking at schema binding, use alias. Proposal: same logic is to be used when there is no schema binding or the user chooses not to use it.
<johnarwe> 6 and 7 describe the processing for schemaLocation on include, redefine, xsi:, import
<johnarwe> current draft is somewhat different from proposal. restructuring probably required to be clear when each rule applies.
Kunar: It seems that everyone agrees to the principle; need to be considered by editors.
Resolution: Accept 17.14.1 for section 5.5: item 3 should be followed regardless of schemabinding is present or is ignored.
Kumar: Processing of redefines/include will be the same.
<johnarwe> so that "no schema bindings" handling of schemalocation agrees with case when schema bindings are there
<johnarwe> ...and the consumer supports them
MSM: Agreement seems to conflict with 3.d and 3.c in current editor's draft.
John: this should be a separate
question.
... instruction to editors- Kumar is pointing out that nesting
is incorrect is 5.5.
<MSM> [I apologize; I think I led us into a rat-hole. I overlooked the condition in 2.c/d and 3.b/c on whether the IF document is schema-complete or not.]
Point 3 in comment 14 in 17
John:See comment 16. This says what you want.
scribe: Editorial restructuring is required.
Proposal 17.14.3 go to Editors to resolve. (Editorial)
John: need structural change so as to make sure the case is covered
Zulah and MSM want review of any proposal
<johnarwe> comments 15 and 16 of 4774 suggest some ways to fix
Resolution: 17.14.3 give to Editorials. Editors will propose solution for review.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4687
Proposal: Allow base64 for all documents, required for those containing DTDs
<johnarwe> current text: There MUST be at most one document embedded
MSM: bottom at point 1:recommends changing to statement: There MUST be at most one.
<johnarwe> msm proposes: There MUST be at most one document embedded
<MSM> also for point 2
Zulah: MSM's comments apply to both points 1 and 2
Resolution: 4687 is Editorial as amended by MSM.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5091
Ginny: These changes assume
normative unless explicitly marked non-normative.
... We need to reference the example appendices in text.
Valentina: Original text did not make this necessary
Resolution: We accept proposed 5091 as wholly fixed. Open new bugs for changes.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5303
Ginny: Question regarding how to process 2 URIs.
Sandy: The SML URI does not flag an error because it might be some other scheme.
MSM: Have we created a situation in which some erroraneous schemes will not be identified?
John: This is a situation because
of schemes with overlapping content.
... two editorial comments in comment #1 and comments 4 and
5
Resolution: No objection to making 5303 editorial.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5063
John: Discussion on last call.
MSM: Continue to fear complexity
to write to enforce this. There is a question of alignment, but
it is a question of alignment in a design pattern rather than
technical matter.
... Only Type assignment needs to be preserved across
restriction. Not a contradiction for us to state that target
constraints across restriction, but rules will be hard to
write.
<zulah> I can't understand Sandy
<MSM> SG: I feared the complexity, too, but now I support the proposal.
I'm also having trouble following Sandy's discussion.
Sandy: Rules will be hard to read in the spec, problem only for implementers.
Kumar: Agrees with Sandy that implementers could keep alignment with schema.
Ginny: Ok with Kumar's proposal.
<zulah> The issues that SML has with inheritance and assertions are applicable to all Schema users and should be fed into Schema 1.1
Zulah: Issues are general issues with schema inheritance.
<zulah> Much of the design for SML's inheritance is better factored into Schema 1.1
<zulah> This should be sent to the Schema 1.1 group which should address this issue. Not SML
Zulah: This issue should remain
open at this point.
... Thinks that it will be difficult for SML to get this
correct. Resolution belongs in XML Schema 1.1 WG.
... Clarifies that this concerns pertains only to this
issue.
<pratul> Kirk, Zulah said that "Resolution belongs in XML Schema 1.1 WG"
Zulah: Inheritance issues belong
to Schema WG 1.1
... Issues exist for all schema issues and the work be handed
off to Schema WG.
<MSM> [The problem we have labeled 'alignment with XML Schema' is precisely the fact that in XML Schema, constraints on elements contained in complex types are not guaranteed to be preserved across complex type restriction. If XML Schema had a clearer story on that topic, then the task of SML in describing this constraint on the target* constraints would be far simpler.]
Zulah: Objects to closing this particular bug and would like to have more discussion.
Pratul: We don't have a dependence on Schema 1.1.
Kumar: This will keep our group hanging for a long time.
John: Strawpoll. Who would object closing this bug as Kumar proposed per sandy's comment in #7?
MSM: there is an architectural issue here. It is premature to close this bug at this time.
Jim: No problem with statement in comment #6. We need to come up with a schedule for closing this and plan.
<Jim> I suggest we not close it without entertaining the possibility that another option be taken.
Ginny: We need to support the request not to resolve this issue due to objection from Zulah and MSM.
Jim: HP does not have issues as laid out by Kumar.
Kumar: It doesn't make sense to
have issues addressed by Schema. 1.1 WG
... What is technical issue?
Zulah: Technical issue is that we need to consider architectural issue. These are larger than SML WG.
Kumar: What IS the architectural issue here?
<zulah> We believe that going to LC with will slow the progress of SML
<MSM> Zulah: the technical issue is the one identified in 5063: inheritance of constraints on element declarations across complex type restriction
Kumar: We are not changing XML Schema constraints, this is an issue of SML constraints that are not handled by Schema 1.1 WG.
Zulah: BEA's contention, if
Schema 1.1 addressed these issues, then SML wouldn't have
to.
... BEA does not yet have a proposal at this point. It needs
more discussion.
Kumar: This is not an Schema 1.1 architectural issue.
MSM: Complex type restriction
propagate across restriction, but contraints on child element
declarations do not propagate.
... In 5063, we want our constraints to behave different.
... Therefore, Schema has gotten it wrong.
<johnarwe> MSM: note that when doing derivation by restriction in schema, constraints on types are automatically inherited and constraints on elements are not automatically inherited.
<johnarwe> next meeting Jan 3
<johnarwe> request to BEA to email some details on their issue, including a proposal, while people are out next 3 weeks.
<johnarwe> Zulah notes BEA has forced closure next several weeks, so may need to wait several weeks into Jan for a thorough proposal.
Last Scribe Date Member Name Regrets pending 2007-08-30 Lipton, Paul until mid-January 2007 2007-11-15 Lynn, James 12/24, 12/27, 12/31 2007-11-19 Valentina Popescu 12/24, 12/27, 12/31 2007-11-26 Boucher, Jordan 12/24, 12/27, 12/31 2007-11-29 Gao, Sandy 12/17, 12/20, 12/24, 12/27, 12/31, 01/03 2007-12-03 Kumar, Pandit 12/17, 12/20 2007-12-06 Eckert, Zulah 12/17, 12/20, 12/24, 12/27, 12/31, 01/03 2007-12-10 Smith, Virginia 12/17, 12/24, 12/27, 12/31 2007-12-13 Wilson, Kirk 12/24, 12/27 Exempt Arwe, John 12/17, 12/20, 12/24, 12/27, 12/31 Exempt Dublish, Pratul Exempt MSM 12/24, 12/27, 12/31 Exempt PH=