See also: IRC log
Minutes of 7/17: http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0042/20080717-sml-minutes.html
RESOLUTION: Minutes approved without objection
Pratul: Henry has submitted
comments, MSM essentially agreed.
... point 1 was dropped from John's proposal.
MSM: Curious as why point 1 of John's proposal was dropped. Why is it dropped from document level?
Kumar: based on point 3, since it optional
Ginny: based on what implementations are doing.
MSM: Point 1 helps support the
eventual dropping of smlif:baseURI together.
... Would prefer not to protect more of existing code than
needs to be protected.
Ginny: Agrees.
NOTE: SCRIBE LOST CONNECTIVITY TO IRC FOR SEVERAL MINUTES
Kumar: MS will continue to support smlif:baseURI. These should not be part of interop cases.
Ginny: Henry wants a stronger statement of deprecation than the proposal makes.
Kumar: If allow only on model, scenarios for which we introduced smlif:baseURI will not work.
MSM: Two reasons: (1) the
situation SG described seems less important to me than the
principle of encouraging people to move to xml:base, (2) If I
want to guarantee interoperability if both are optional, then I
would absolutize URIs.
... No positions have changed; I have asked for an explanation,
and have now gotten it, for which I thank the WG. If no minds
have been changed, we should leave the proposal as is.
Pratul: Does anyone want this to be reopened?
Pratul: Let's look at Henry's comment.
Sandy: Questions whether a consumer can support neither form of baseURIs
Ginny: Expressed objection last week.
Pratul: Whole issue should be considered?
Ginny: Would like to discuss point 5.
<pratul> Sandy and Ginny requested that we reopen the discussion on 5542
MSM: Sandy and Ginny are suggesting a point 6: Consumers must support one or the other
<MSM> [If I'm understanding this correctly, the consequence would be that if I produce an IF package with *both* smlif:baseURI and xml:base, then all consumers will be guaranteed to understand the package correctly.]
<MSM> [That would have the consequence that to get universal guarantees of readability I don't have to absolutize all URIs.]
<MSM> [This helps IF packages avoid being verbose and illegible.]
<MSM> [Is that about right?]
Kumar: MS has no intention to remove smlif:baseURI. Probably same for COSMOS.
Ginny: It is harder for the
producer to know if the model is interoperable.
... Thus both become useless for "pure" interoperability (i.e.,
producer doesn't know who the consumer is). Neither of these
are useful.
<MSM> +1 to Ginny's argument, as I understand it, that this is one barrier to interoperability that we do not have to impose. I think the versions of external specs are a special case; this one is just internal to our spec.
Kumar: This is not a special with regard this feature; it pertains to all optional features.
Sandy: Agrees that every optional features has this problem, which is why we try to limit optional features.
<MSM> I suppose there are two ways to apply the floor/ceiling analysis: require xml:base for consumers, or require one-or-the-other.
Pratul: Have a statement that at
least one of the other must be supported?
... Sandy agrees.
<MSM> PD proposal (as MSM heard it): add point 6: Consumers are required to support at least one of xml:base and smlif:baseURI
Pratul:Point 6 and deprecating smlif:baseURI appear to be incompatible.
MSM: Doesn't see
incompatibility
... Weird but not a logical contradiction. Gives direction for
those using smlif:baseURI.
Pratul: Consumer must support at least one of smlif:baseURI or xml:base. Then say that smlif:baseuURI is deprecated.
Kumar: Clarifies the meaning of "deprecation": smlif:baseURI is continued to be supported in SML 1.1, in future version support MAY be dropped.
MSM: What this means in practice,
people who want to preserve feature CANNOT claim that it will
break current implementation.
... Clarifies that the current proposal (specify deprecation today),
implies that the feature might be removed in NEXT version. If statement occurs
in next version, then it is still supported in THAT version, and will not go
away in a subsequent version after that.
... The first meaning is what Henry is interested is trying to
get at.
Kumar: Word "deprecated" causes confusion. Just say explicitly what it means.
Ginny: The statement would not be as strong as "deprecated".
MSM: Agree with Ginny.
... We should define "deprecated" but use the word.
... The word "Deprecated" carries the connotation: It is
advisable not to use it.
<MSM> What I believe HT is suggesting (and what I would support) is addition of a sentence saying something like:
<pratul> One interesting definition of deprecate - Archaic. to pray for deliverance from.
<MSM> The smlif:baseURI feature is supported in this version of this specification for compatibility reasons. It is, however, deprecated and may be removed in a future version of this specification.
<MSM> or possibly: it is, however, deprecated: it may be removed in a future version of this specificaiton, and users of this specification are advised to avoid using it if possible.
<MSM> -- end of proposal --
Pratul: First proposal is
preferred.
... Is everyone happy with this proposal?
No objection.
Pratul: Are we happy with saying consumers must support either smlif:baseURI / xml:base.
No objection
<pratul> Consumer must support at least one smlif:baseURI and xml:base.
<pratul> The smlif:baseURI feature is supported in this version of this specification for compatibility reasons. It is, however, deprecated and may be removed in a future version of this specification
Pratul: Any objection?
No objection.
Ginny: There is still comment 7b:
Pratul: 7b applies to situation in which consumers supports both.
Sandy: Compute from xml:base, if that fails, use smlif:baseURI
RESOLUTION: Fix 7b per Sandy's comment above, mark 5542 as Editorial, needsReview.
Pratul will send email to Henry to get his approval on our approach to comments 7a and 7b.
Review of comment #7.
MSM: Assume same thing to be true of DTD-validation.
Pratul: This sounds reasonable.
Kumar: Proposal is not to do DTD validation.
<Kumar> Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation defined.
MSM: No.
... Barenames for things identified as ID. Things are
identified as ID by either Schema-validiation or DTD-validation. It is
implementation defined whether you use Schema or
DTD-validation?
... Or does it mean something else?
<MSM> i.e. Is this a correct understanding of the convergence identified in comment #7? (1) Barenames must be supported for attributes recognized as IDs. (2) Attributes can be recognized as IDs either by means of DTD or by means of schema-validity assessment. (3) Except as otherwise specified in this spec, the circumstances under which DTD-validation and schema-validity assessment are performed (and thus: the circs under which bare names are supported in practice).
MSM: This does not exclude elements.
<MSM> One difference at issue is: is it / should it be implementation-defined whether a processor which does perform DTD-based validation supports barename references using IDs declared in the DTD? I take Sandy's propposal to lean toward saying no, in that case you really are expected to support them.
MSM: Should proposal state about what a DTD processor should do? Is it implementation-defined what to do here; or is the recognition implementation-defined.
Sandy: Implementation-defined whether to expose the DTD information.
MSM: Complexity of explaining
this is getting too high; therefore preferring Kumar's
explanation. Would prefer more interoperability, but this is
too complex.
... All aspects of DTD validation is implementation-defined.
Let's not worry about what happens if a DTD process does
not--all processors tend to do this.
Pratul: Use the wording suggested by Kumar above for resolution of this issue.
<pratul> Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation defined
No objections
<MSM> [I would be glad if the minutes could show that my first preference would be for a simpler and more general statement that barenames must be supported. I don't think XML processors that don't expose attribute types are worth supporting as components of an SML system. But I can live with this resolution in the interests of compromise and moving forward, and I rather hope that Henry will be able to live with it too, though I do not speak for him.]
RESOLUTION: Add the preceding text entered by Pratul to the bug. Mark as Editorial, needsReview.
Pratul will close the loop with Henry.
Ginny: Example seems OK to use deref(). But in subsequent context, it is not.
Pratul: Let's skip this issue.
Ginny: Agrees.
Kumar: It seems that it is OK to make strict-wildcard the default.
MSM: In practice, all processors support this mode of invocation. But schema spec does not constrain the invocation model.
No one has reason to disbelieve that these are supported in the stack.
Pratul: Thus there is no dependence on Schema 1.1
MSM: Suspected that we would
allow unknown validity only when we fall back to
lax-processing.
... We need to rules for when we except an applicable schema
there is one or none.
... easiest why to describe these rules with with
strict-/lax-wildcard processing.
Kumar: We only say that the root element must not be invalid.
MSM: This is lax-wildcard
mode.
... What do what do we want behavior of SML validator to
be?
Discussion of these issue with MSM and Kumar.
<MSM> Note: ... In typical cases strict wildcard validation will be performed when the invoking process expects the ·validation root· to be declared and valid and will otherwise report an error to its environment. If the absence of a declaration for the ·validation root· counts as a successful outcome of validation, then it is preferable to use lax wildcard validation instead.
<MSM> Note: From the point of view of schema-validity assessment and the resulting ·post-schema-validation infoset·, lax and strict wildcard validation produce the same result. The distinction is provided in order to provide two different terms to express the different expectations of the invoking process.
<MSM> In typical cases strict wildcard validation will be performed when the invoking process expects the ·validation root· to be declared and valid and will otherwise report an error to its environment. If the absence of a declaration for the ·validation root· counts as a successful outcome of validation, then it is preferable to use lax wildcard validation instead.
<MSM> The name for this method of invocation reflects the fact that it is analogous to the validation of an element information item which matches a strict wildcard.
MSM: Difference in the terms is
used to reflect the difference in the attitude of the
caller.
... Do we want one behavior or two behaviors. Understood
convergence of the group to be two behaviors.
... Recollection from F2F: we want more complex behavior. We are in
the business of what we want the spec to say.
Kumar: Not change section 8, but an issue of how the schema processor is invoked.
Ginny: Agree with MSM's description of what the group was considering.
Pratul: We will take this up at next meeting.
Adjournment: 4:06 ET.
Last Scribe Date Member Name Regrets pending 2008-05-22 Lynn, James 2008-06-24 Kumar, Pandit 2008-06-25 Smith, Virginia 9/4, 9/11 2008-07-10 McCarthy, Julia 2008-07-17 Gao, Sandy 2008-07-24 Wilson, Kirk Exempt Arwe, John 7/10 - 8/5 inclusive Exempt Dublish, Pratul 8/28 Exempt MSM