See also: IRC log
<scribe> scribenick: Kirk
<scribe> scribe: Kirk Wilson
<pratul> Julia sent her regrets
Minutes of 7/17
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 sml:baseURI together.
... Would prefer not to protect more of existing code than
needs to be protected.
Ginny: Agrees.
<Kirk3> zakin, Kirk3 is Kirk
<Kirk3> scribe: Kirk3
Kumar: MS will continue to support sml: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 sml: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 option, 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?
No requests to reopen the issue.
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
Ginny: IS anticipating agreement with Henry's comments.
<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?]
<kirk> scribe: Kirk
Kumar: MS has no intention to remove sml:baseURI. Probably same for COSMOS.
Ginny: It is hard 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 regarding to 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: incompatible with this point 6 and deprecating smlif:baseURI.
MSM: Doesn't see
incompatibility
... Weird but not a logical contradiction. Gives direction for
those using smlif:baseURI.
Pratul: Consumer must support must at least one smlif:baseURI and xsml: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 (deprecation today),
then it might be removed in NEXT version. If statement says
(last week), deprecated 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 interestin 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 must 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: 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.
MSM: No.
... Barenames for things identified as ID. Things are
identified as ID by Schema-validiation, DTD-validation. It is
implementation define 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 to 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 to the issue. 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 processor 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: From SML point of view, then strict wild-card requires [validity] property to be VALID.
<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 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: While take this up at next meeting.
Adjournment: 4:06 ET.
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 0.97) Succeeded: s/comment/point/ Succeeded: s/project/protect/ Succeeded: s/less important for moving to xml:baseUri,/the situation SG described seems less important to me than the principle of encouraging people to move to xml:base,/ Succeeded: s/I have asked for explanation./I have asked for an explanation, and have now gotten it, for which I thank the WG./ Succeeded: s/There is/MS has/ Succeeded: s/submitted/supported/ Succeeded: s/one of/at least one of/ Succeeded: s/Proposal/PD proposal (as MSM heard it)/ Succeeded: s/compatible with/incompatible with/ Succeeded: s/Note/sentence/ Succeeded: s/sound/sounds/ Succeeded: s/The difference/One difference/ Found ScribeNick: Kirk Found Scribe: Kirk Wilson Found Scribe: Kirk3 Inferring ScribeNick: Kirk3 Found Scribe: Kirk Inferring ScribeNick: kirk Scribes: Kirk Wilson, Kirk3, Kirk ScribeNicks: Kirk, Kirk3 Default Present: Kirk, MSM, Kumar, pratul, Sandy, Ginny_Smith Present: Kirk MSM Kumar pratul Sandy Ginny_Smith WARNING: Replacing previous Regrets list. (Old list: Jim) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Julia Regrets: Julia Jim WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 24 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/24-sml-minutes.html People with action items:[End of scribe.perl diagnostic output]