See also: IRC log
<MSM> http://www.w3.org/XML/2007/08/xml1011.html
<Paul> Link above is for XML 1.0 and XML 1.1 Presentation by MSM
<Paul> Scribe: Paul Lipton
<Sandy> bug 4630
<Paul> Discussion/Presentation by MSM on general problems on referring to other specs will also be discussed.
<Paul> MSM: Generally thinks people are too worried about things like new chars
<Paul> MSM: Parsers may have to be changed, but why worry about downstream apps?
<Paul> MSM: Has not heard reports of problems, but there is a fear of 1.1.
<Paul> Pratul: What are the things that may need to be fixed with a possible XML 1.2, mentioned in slides?
<Paul> MSM: XML 1.2 is very preliminary. Basic idea is to minimize potential problems like some 1.0 problems are not legal 1.1. Don't have more info at this time.
<Paul> MSM: XML 1.0 processors can quite if they want (don't have to) in the face of later versions. Errata later on said 1.0 processor MUST fail. This is a problem for processing 1.1.
<Paul> ... some thought that errata is itself a problem.
<Paul> Kumar: How many of the people who were not enfranchised due to limitations in 1.0 are now using 1.1?
<Paul> MSM: Not sure
<Paul> John: Difference between producers and consumers (cites Xerces as supporting both)
<Paul> Kumar: Any idea of number of vendor?
<Paul> MSM: no
<Paul> Paul: When was it recommended?
<Paul> MSM: 2003ish, not exactly sure
<pratul> It was published on 4 Feb 2004
<Paul> Kumar: What provision for breaking in existing 1.1 processor?
<Paul> MSM: Committment for additive changes only
<Paul> s /breaking/breaking change/
<Paul> MSM: Loose-coupling means certain aspects of data of interest will be in other specs.
<Paul> Kumar: if we decide to base on xml 1.1, then some xml 1.0 apps may break. Specs that are depended upon can break dependent specs. Expressed concern about customer viewpoint and being realistic.
<Paul> MSM: Separation of concerns is strong justification. The guys in the other spec knew what they were doing.
<Paul> Kumar:What do other people think of relying on latest version of XML? To me, it sounds precarious.
<Paul> Jim: To me, if we take path of last bullet item in pres (slide 20) this might address your concerns because XML 1.0 is still the base and safe, but leaves freedom for vendors/customers to use XML 1.1.
<Paul> John: One complication we may have is when there is multple documents and there is a mix of XML 1.0 and 1.1 involved. We have to decide to not deal with it or perhaps something else.
<Paul> John: What if your flags are "1.0 strict," for example, how do you deal with this?
<Paul> MSM: A conforming xml 1.1 processor must support 1.0
<Paul> MSM: The implementation will have to note incompatibility with runtime options independent of SML
<Paul> MSM: Separate from violation of SML spec, of course.
<Paul> Pratul: How 1.0/1.1 supported should be up to my implementation to decide.
<Paul> MSM: One issue might be (related to yesterday's issue about target type constraint) is one of the possible solutions (not chosen) was you have to use same schema for both documents. If we did choose that option, then it would be possible to construct cases where the validity of a doc may vary according to NC name type.
<Paul> John: If producer created sml-if of 1.0 and 1.1 documents how much do we want to constrain that?
<Paul> Kumar: If consumer is 1.0 only, it can reject it.
<Paul> John: Question is what does our spec need to say to constrain possiblities. We can say no in mixed mode. Pratul said for stuff later than 1.0, say nothing is outside scope of spec.
<Paul> John: Any problem with Pratul's suggestion of fixed floor to specify interoperability and allowing later versions of related spec freely (implementation defined). Suggest words from Schema that put a should on it (the very bottom bullet on wording from slide 17 and bullet from bottom from slide 20)).
<Paul> MSM: Schema does not have a signal about version
<Paul> MSM: You can tell if it is valid against a 1.0 or 1.1, of course.
<Paul> Resolution: No objections to John's assertion above.
<Paul> MSM: Consensus on general principle here.
<Paul> John: What about specific XML 1.1 question? General principle - is that OK?
<Paul> Pratul: General principle includes relying on other specs. We specify a floor, but not a ceiling.
<Paul> John: For each specific case, we will choose a specific spec that will serve as a floor. Is anybody uncomfortable with this?
<Paul> Resolution: Above resolved as per John.
<pratul> And conforming implementations must support the selected floor
<Paul> John: XML 1.0 / 1.1 decision. Are we satisfied with applying the general principle here?
<Paul> Kirk: We have to keep in mind future versions.
<Paul> Jim: I propose that we adopt XML 1.0 as the floor as a general principle unless there are specific issues later.
<Paul> Resolution: XML 1.0 is the fixed floor.
<Paul> Marv: Propose we want to add the boiler plate encouraging implementors.
<Paul> MSM: W3C has specific rules for IP. Regarding references there is not a strict rule.
<Paul> Marv: This is ISO boilerplate that we saw on slide 17.
<Paul> Marv: That wording or something analogous.
<Paul> Sandy: We should wait until we agree on all references.
<Paul> MSM: We can adjust it lateras necessary if we end up with a special case.
<johnarwe> Sandy: ok with adjusting it later, giving editors latitude to impart the correct spirit
<MSM> http://www.w3.org/XML/2007/08/xml1011.html
<MSM> The ISO wording being discussed is:
<MSM> The following normative documents contain provisions which, through reference in this text, constitute provisions of this [spec]. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this [spec] are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative
<Paul> s /slide 17/slide 17/
<MSM> slide 17 in the current (revised) slides, although it may have been 16 in the slides I presented from
<MSM> SG presents slides on XML Schema 1.1
<Paul> scribe: Paul
<scribe> ScribeNick: Paul
<MSM> http://lists.w3.org/Archives/Public/public-sml/2007Aug/att-0085/20070829_-_Schema_1.1_for_SML.ppt
<MSM> http://lists.w3.org/Archives/Public/public-sml/2007Aug/att-0085/20070829_-_Schema_1.1_for_SML.pdf
Sandy: There are 1.0 schemas that
are no longer valid under 1.1. But people should not have been
using the breaking structures.
... There are 1.0 schemas that are no longer valid under 1.1.
But people should not have using the breaking structures.
<PCL> MSM: Schema wg (I think) will not go to req pointing to something still changing
<PCL> scribenick: PCL
Pratul: Are these new types required.
Sandy: These types are always
there and must be supported.
... In the new versions of these specs.
Slide 4
Kumar: (referring to slide 5) so today you have to respecify.
Sandy: Yes.
Pratul: Can you do assertions on any global declarations?
Sandy: Only complex types
Valentina: (slide 5) is messageType a string?
Sandy: is a type and the alternative elements have the derived types.
Paul: Can be default
Sandy: yes
John: Sandy, what is your proposal?
Sandy: Requiring 1.0 and allowing 1.1 and beyond probably makes sense.
Jim: What do we think of chosing only Schema 1.1?
Pratul: There is a possibility
that 1.1 won't go through.
... May have to changes some terms, etc. in spec.
<johnarwe> if 1.1 does not go to Rec "soon enough" sounds analogous to the situation we heard about already with schema 1.1's relationship to IEEE754r
MSM: I don't think we would have to change SML schema examples.
Pratul: I was worried about sections that define semantics.
Jim: Correction. I was really
saying you must support 1.0 or 1.1.
... You could support 1.1 (if you want) instead of 1.0.
John: How do we get deterministic interop if there is more than one floor?
Jim: Answer may be that Schema
1.1 support still means you can handle 1.0 docs.
... If we don't require schema 1.0, are we killing interop?
Sandy: yes and benefit unclear.
John: Proposal for fixed floor
schema 1.0 and anything else allowed. Any discomfort?
... This is a proposal by Sandy
Resolution: Agreed
Paul: ... Current minutes only being generated by rrsagent in pieces. MSM will help address this.
<ginny> P38 is not /me
<Kirk> zakin, ??P38 is Ginny
MSM: 2.0 is superset (largely
compatible) with 1.0, but if we mandate 2.0 it will mean more
work for implementors.
... Lots of extra power in 2.0, though (bigger language)
<MSM> http://www.w3.org/XML/2007/08/xpath1020.html
John: Any xpath 2.0 proposals?
Kumar: Proposal to make floor would be 1.0 and open ceiling.
John: Any objections on Kumar's proposal?
Resolution: Floor is 1.0 and open ceiling
Jim: Can we address the URI/IRI issue?
Pratul: Phillip said IRI should be mandatory (I seem to remember)
MSM: Phillip is not on IRC, would prefer to not represent him without being able to chat with him
Sandy: 3 bugs open related to xpath/schema/xml - what should we do?
John: Any objections to updating
bugs and changing state to editorial?
... No decisions yet on schematron, btw.
<MSM> bugs 4628, 4629, and 4630 appear to be movable now from needsAgreement to needsDrafting
<MSM> sl/needsDrafting/editorial/
John: Schema reviewers would
certainly care about xml and schema revisions
... we have all the editors here or on phone
... Any risk, editors, with moving these 3 issues to second
draft?
Ginny: OK
Jim: OK
Ginny: what does note on schematron mean?
John: 4629 - look at that
... To deal with schematron portion of 4629, do we know what to
do or do we need proposal?
Pratul: somebody should read
normative appendix
... Schematron spec leads one to believe default binding is
1.0. We need to decide in sml what is query binding in context
of schematron rules.
... We could say, for example binding is xpath 1.0 (for
query)
Ginny: you can decide binding on your own, Schematron says
<MSM> The Schematron spec at http://www.schematron.com/iso/P16.html reads in part (in annexe C):
<MSM> A Schematron schema with no language binding or a language attribute with the value xslt, in any mix of upper and lower case letters, shall use the following binding:
<MSM> — The query language used is the extended version of XPath specified in XSLT. Consequently, the data model used is the data model of those specifications.
John: Is there discomfort with us saying fixed floor with current ISO version of schematron and allowing future versions if they come to pass?
Pratul: agree
Resolution: Yes to John's proposal. Add decision to 4629
<Sandy> The queryBinding bug is 4977.
<johnarwe> scribe: Kumar
<scribe> scribe: Kumar
msm: having document based cycles
is easier implementation wise.
... in real world scenarios we are not likely to see cycles
because the types involved in a ref relationship are usually
different
<trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/2005/06/tracker/sml/
kumar: there are perf problems with element based cycles. with document based cycles and a sql server based store, it is much easier to index on document identity columnl. if we have element based cycles, we need to use xpath (unlimited length string) as the element identity. this makes it very hard to have a performant solution because we cannot directly index on such a column.
john: we can alleviate the problem to some extent by checking constraints at predermined time (low load) rather than at each insert.
kumar: yes, that is an option.
jim: if we do not adopt element based cycles, would we harm sml's adoption?
john: not likely.
... should we fix 4639 for second draft?
ginny: why not postpone it to LC?
john: it is better to not
postpone a lot of bugs to LC
... we need someone who cares about having element based cycles
to own the bug and drive it. do we have someone for that?
<trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/2005/06/tracker/sml/
<Sandy> <complexType name="hostType">
<Sandy> ...
<Sandy> <annotation>
<Sandy> <appinfo>
<Sandy> <sml:acyclic ref="./ref"/>
<Sandy> </appinfo>
<Sandy> </annotation>
<Sandy> </complexType>
<scribe> ACTION: Jim to make a proposal for the definition of an element based cycle. [recorded in http://www.w3.org/2007/08/30-sml-minutes.html#action01]
<trackbot-ng> Sorry, couldn't find user - Jim
<scribe> ACTION: James to make a proposal for the definition of an element based cycle. [recorded in http://www.w3.org/2007/08/30-sml-minutes.html#action02]
<trackbot-ng> Created ACTION-121 - Make a proposal for the definition of an element based cycle. [on James Lynn - due 2007-09-06].
ginny: would like to keep the bug open and would like to have element based cycles mandatory.
<MSM> ADJOURNED.
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/existing/in existing/ Succeeded: i/What do other/Topic: Discussion of applying these principles from MSM to SML Succeeded: s/vary./vary according to NC name type./ Succeeded: s/slide 20/wording from slide 16 and bullet from bottom from slide 20)/ Succeeded: s/base/floor/ Succeeded: s/rules/rules in general/ Succeeded: s/rules in general/rules for IP/ Succeeded: s/it /it later/ Succeeded: s/slide 16/slide 17/g Succeeded: s/have/have been/ Succeeded: s/1.1/1.1 and beyond/ Succeeded: s/Fixed/Proposal for fixed/ Succeeded: s/Floor/Proposal to make floor/ Found Scribe: Paul Lipton WARNING: "Scribe: Paul Lipton" command found, but no lines found matching "<Paul Lipton> . . . " Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Found Scribe: Paul Inferring ScribeNick: Paul Found ScribeNick: Paul Found ScribeNick: PCL Found Scribe: Kumar Inferring ScribeNick: Kumar Found Scribe: Kumar Inferring ScribeNick: Kumar Scribes: Paul Lipton, Paul, Kumar ScribeNicks: Paul, PCL, Kumar Default Present: SMLF2F, Ginny Present: Kumar Pratul John Jim Ginny Sandy Valentina Paul Marv Kirk WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 30 Aug 2007 Guessing minutes URL: http://www.w3.org/2007/08/30-sml-minutes.html People with action items: james jim[End of scribe.perl diagnostic output]