See also: IRC log
<scribe> ACTION: John to remember to add link to 10-15 F2F minutes on next week's (11-08) agenda. [recorded in http://www.w3.org/2007/11/01-sml-minutes.html#action01]
<trackbot-ng> Created ACTION-148 - Remember to add link to 10-15 F2F minutes on next week's (11-08) agenda. [on John Arwe - due 2007-11-08].
RESOLUTION: Oct 25 minutes approved.
Pratul: beginning of the weeks as
we asked; please register early.
... Jan. meeting requires $150 registration fee.
... Fee charged to credit card supplied when you register.
registration info email
Ginny: 4th proposal from
Kumar.
... will update the document. don't think ready to
discuss/decide today.
Kumar: propose an amendment to
the proposal in comment #4.
... producers must normalize if there's a DTD; consumers
process IF doc normally (including handling a top level
DTD).
Sandy: the only thing that's not supported is the schema entity type. all the values will become invalid if the DTD is removed.
Kumar: the unparsed entities can be added to the root DTD
Sandy: then there may be collisions from multiple documents; also when the IF is unpackaged, how to reassign these entities to the individual documents?
Kumar: I think this is a corner case. We can add it later. (the next version of the spec) we don't have time.
Pratul: or we can do only 1.2 in comment #4 for producers.
MSM: prefers what's currently in comment #4. am OK with "just base 64".
Kumar: can't live with proposal in comment #4. it may have complications on document signature. and we haven't had time to think through it.
Pratul: straw poll
Sandy: I like proposal in #4; can live with just 1.2; uncomfortable with just 1.1.
Jordan: no opinion at this point
Kirk: prefer 1.2 only; can live with any other solutions.
Kumar: Prefers 1.1 only. if other options are considered, we need to consider other related issues, which requires more time.
Valentina: prefer 1.2 only
Ginny: OK with comment #4; also OK with 1.2 only (1.1 is allowed anyway).
Zulah: 1.2 only
Pratul: can we agree on 1.2 only; if there's new information arising from the signature issue, it can be reopened.
Kumar: wants to spend more time on this and report back. not sure what impact this has on the rest of the spec and impl.
Pratul: WG leaning toward 1.2 only. Kumar to point out potential problems.
RESOLUTION: conditional consent for 1.2 only. pending Kumar's research result.
Sandy: working on a proposal. Suggest to discuss next week.
Kumar: not our business for SML
to define how to report schematron errors. we don't even do
that for SML errors.
... and it's not important, and should wait till after other
important tasks are done.
John: different WG members may have different views on the importance of these issues.
Pratul: straw poll about importance of this feature. should smlerror:output be kept in the spec?
Jordan: should be taken out.
Kirk: no opinion.
Kumar: drop everything related to smlerr:output.
Sandy: no opinion
Valentina: would help to talk to those who wanted this to understand why they thought it was necessary. don't want to take this out until we know no one needs it.
Ginny: take out
Zulah: no opinion. don't recall any particular use case.
<zulah> the original SML group did not have any strong use cases for this. However there were members who wanted it. My sense is that if someone can demonstrate a strong need via a use case, then we should consider it. However, at this point, we could remove it and reintroduce it if a use case emerges.
<zulah> I'm concerned that we have discussed this on several occasions now and it does waste our time.
Pratul: I wrote this section. If it helps, I can try to go back and investigate the history and report back.
Kirk: sent a document summarizing the situation.
Kumar: comment #4 seems to be
based on some assumptions.
... "scope" is a means, not a goal. the goal can already be
achieved with what's currently in the spec.
Sandy: it depends on what the goal is. if it's only validity, then yes, it's already achieved; if the goal is to refer to existing keys, then it's not achieved.
Kumar: goal is "being able to
refer key sequences existing in other documents".
... second assumption: "the schema author writing the key ref
knows how to write the key ref".
... third assumption: "unlike keyref, the schema author of the
keyref has no control over how the keys are defined".
... if I have control over keys and keyrefs, I can put them
wherever I find that makes most sense to me.
Ginny: 2 cases. one is keys
already exist. if they match, then use them instead of copying
them. the other is when the desired keys are not available,
then new ones are defined.
... should cover both these cases. the "scope" proposal covers
both cases. copying always sounds problematic.
Pratul: continue discussion in email; pick up next week.
Ginny: is there a difference between conforming SML model and valid SML model?
John: yes.
Kumar: split second half of
section 7 to 2 lists. the first contains current 1-3 for
conforming; the second contains 4-7 for validity.
... Then we can adopt Ginny's suggestion.
Sandy: If document criteria
requires #ALL, then how can a program running not in #ALL mode
be called a conforming validator?
... will add a comment to the bug entry.
Last Scribe Date Member Name Regrets pending 200y-mm-dd Vijay Tewari 2007-06-12 Tabbara, Bassam 2007-08-30 Wilson, Kirk 2007-08-30 Lipton, Paul 2007-09-20 Lynn, James 2007-10-04 Smith, Virginia 2007-10-16 Valentina Popescu 2007-10-15 Waschke, Marvin 2007-10-17 Eckert, Zulah 2007-10-17 Kumar, Pandit 2007-10-24 Boucher, Jordan 2007-11-01 Gao, Sandy Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH