See also: IRC log
Resolution: approved
MSM: action 114. Don't know what it's about. Propose to close it silently.
<MSM> If an SML identity constraint is specified for an element declaration E, then this constraint is applicable to all instances of E in a model, i.e., the identity constraint MUST be satisfied for each instance of E in a valid model
<johnarwe> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4801
Resolution: leave both action 114 and bug 4801 "open" for another week. If no new information surfaces, close both.
Valentina: 122 is done. Expect to finish 118 next week.
<johnarwe> http://www.w3.org/2005/06/tracker/sml/users/29374
MSM: PLH's actions 116 is overtaken, because we closed the relevent IRI/URI bugs.
<johnarwe> http://www.w3.org/2005/06/tracker/sml/actions/97
<johnarwe> http://lists.w3.org/Archives/Public/public-sml/2007Jul/0075.html
John: PLH's action 97. Suggest that editors take this over.
Jim: I will follow up with this one.
John: 115 is done.
Kumar: the "yes" branch could also go to the mailing list. sometimes it's easy to do it in emails (in-lined comments).
Resolution: all comments must go to bugzilla; some comments may also go to mailing list (mailing list comments need to be copied to bugzilla)
<scribe> ACTION: John to update the agenda when he puts out meeting minutes (about the "needs review" proposal) [recorded in http://www.w3.org/2007/09/27-sml-minutes.html#action01]
<trackbot-ng> Created ACTION-125 - Update the agenda when he puts out meeting minutes (about the \"needs review\" proposal) [on John Arwe - due 2007-10-04].
<johnarwe> http://lists.w3.org/Archives/Public/public-sml/2007Sep/0237.html
Resolution: accept proposal in mail http://lists.w3.org/Archives/Public/public-sml/2007Sep/0237.html. specifically, bugs stay open when "needs review".
<trackbot-ng> Created ACTION-126 - Update the agenda further about the about process discussion. [on John Arwe - due 2007-10-04].
<johnarwe> http://lists.w3.org/Archives/Public/public-sml/2007Sep/0107.html
Kumar: D2.2 is already covered by V2.1
<MSM> D and V are disjoint algorithms, though.
<Kumar> D2.3 refers to V2.1 ~ V2.4 therefore D2.2 is redundant
<johnarwe> because V2.1 = D2.2 ?
<MSM> Is there a typo in D2.3?
<Kumar> yes to john
<MSM> I am having trouble understanding / parsing " then at least the condition of V2.1~V2.4 ... is true"
Sandy: agree that D2.2 is not needed, but it's because D2.1+D2.4.
<MSM> Perhaps "the antecedent" would be clearer, but an explicit list would be clearer still.
<MSM> But is it necessary to wordsmith this document so finely? If the goal is a coherent story, not spec prose, then redundancy is not dangerous.
<MSM> Question: is the antecedent of V2.4 really a possibility here?
<MSM> If *none* of the antecedents is true, then you MUST return one target.
<MSM> If you return no target, then at least one of the antecedents must be true.
Kumar: change D2.x to be explicit about what happens for different conditions
Sandy: will do
<johnarwe> paragraph starting "In summary, deref() has to obey the "at most one target" rule..."
<MSM> [In sum, I think what SG proposed was:
<MSM> E2.1. If none of the recognized schemes resolves, then no target is
<MSM> returned.
<MSM> E2.2. If at least one of the recognized schemes resolves to more than
<MSM> one target element, then 0 or 1 target is returned.
<MSM> E2.3. If one scheme resolves to a target that’s different from the
<MSM> target resolved by another scheme, then 0 or 1 target is returned.
<MSM> E2.4. If one scheme resolves and another doesn’t, then 0 or 1 target
<MSM> is returned.
<MSM> E2.5. If none of the above is true (that is, all recognized schemes
<MSM> resolve to the same one and only one target element, call it T),
<MSM> then one target is returned (namely, T).
<MSM> ]
<MSM> There are perhaps two "at most one target" rules?
<MSM> 1) the reference must have exactly one target, to be valid.
<MSM> 2) deref() must return at most one target, period
<Kirk> the statement is at best ambiguous--see issue 5070. Deref() must be used to validate constraints
Kumar: note about D2.3: we should require that deref() at least attempt to resolve at least one recognized scheme. to ensure consistent validation behavior between the validators' reference validation and deref() results
Sandy: ok to have that restriction for deref() impls used by validators; but don't want to restrict other deref() impls.
<johnarwe> discussion of the finer points of validating a single ref, validating a model (which includes validating single refs and possibly de-ref'ing them)
MSM: this helps interop?
Sandy: it helps get consistent behavior within the same processor; it doesn't help with interop.
MSM: need to be clear that it improves inter-op, but doesn't guarantee it.
Proposal: deref() implementations used by validators MUST attempt to resolve at least one recognized scheme.
Resolution: adopt the above proposal.
All: clarify that section 5 means "sml:acyclic can be specified on any complex type; sml:target* can be specified on any element declaration".
Kumar: suggest to change title of section 5 not to mention sml reference type, but rather "where can reference constraints be specified".
<MSM> The concept of "SML reference type" is unnecessary and has become extra baggage; it should be deleted.
<MSM> Its function in earlier drafts was to identify where sml:acyclic and sml:targetXXX can be specified.
<MSM> Our answer is now: on any complex type definition or element declaration.
Kumar: agrees to what MSM just typed.
<MSM> Note that a processor may determine, through schema analysis, that valid instances of a particular type will never actually be references; that may be useful for optimization (if we know that all instances are valid), but it does not affect our rules about where acyclic and targetXXX can appear.
Kumar: notes contradiction between section 1 and section 7.
Sandy: Answer to section 1 depends on how we answer section 7
MSM: why is bullet 1 in section 7 much harder to check? seems it's easy for the producer. could consider using the XML "standalone"? property.
<MSM> Proposal (this was what I was reading the document as saying):
<MSM> if sml-if:complete='true', then PSVI MAY be used; results are guaranteed the same whether it's used or not.
<MSM> if sml-if:complete='false', then PSVI MAY be used; results MAY vary depending on whether it is or not.
Sandy: confirms what MSM typed is what the document meant to say
Kumar: "complete" is in another proposal. suggest to define the behavior without mentioning "complete", and say "complete may improve interop".
MSM: 3rd possibility: to use the XML "standalone" property. use PSVI when standalone = false.
Sandy: want to be able to find all references just by looking at the input infoset, which would rule out the "standalone" approach.
John: This was one of the requirements collected before the SML submission.
Sandy: possible problem with
"constrain the producer" approach. if documents are digitally
signed, then requiring producers to always add defaulted
attributes may break the signatures.
... but "constrain the consumer" approach also doesn't satisfy
certain cases, e.g. XInclude.
<scribe> ACTION: Sandy to open a bug about the "digitally signed" case. [recorded in http://www.w3.org/2007/09/27-sml-minutes.html#action02]
<trackbot-ng> Created ACTION-127 - Open a bug about the \"digitally signed\" case. [on Sandy Gao - due 2007-10-04].
Proposal: take the "constrain the producer" approach suggested in section 7.
Resolution: agreed on the above proposal.
Sandy: will update the proposal with these comments, as a reference for the editors.
Scribe list for next meeting
Last Scribe Date Member Name Regrets pending 200y-mm-dd Vijay Tewari 2007-08-09 Waschke, Marvin 2007-08-16 Smith, Virginia 2007-08-28 Eckert, Zulah 2007-08-29 Valentina Popescu 2007-08-30 Wilson, Kirk 2007-08-30 Lipton, Paul 2007-09-06 Boucher, Jordan 2007-09-13 Kumar, Pandit 2007-09-20 Lynn, James 2007-09-27 Gao, Sandy 2007-06-12 Tabbara, Bassam Until 10/30/07 Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH