SML F2F Day 3 -- 30 Aug 2007

<MSM> http://www.w3.org/XML/2007/08/xml1011.html

<Scribe> Link above is for XML 1.0 and XML 1.1 Presentation by MSM

<Scribe> Scribe: Paul Lipton

<Sandy> bug 4630

<Scribe> Discussion/Presentation by MSM on general problems on referring to other specs will also be discussed.

<MSM> Generally thinks people are too worried about things like new chars

<MSM> Parsers may have to be changed, but why worry about downstream apps?

<MSM> Has not heard reports of problems, but there is a fear of 1.1.

<Pratul> What are the things that may need to be fixed with a possible XML 1.2, mentioned in slides?

<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.

<MSM> XML 1.0 processors can quit 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.

<MSM> ... some thought that errata is itself a problem.

<Kumar> How many of the people who were not enfranchised due to limitations in 1.0 are now using 1.1?

<MSM> Not sure

<John> Difference between producers and consumers (cites Xerces as supporting both)

<Kumar> Any idea of number of vendor?

<MSM> no

<Paul> When was it recommended?

<MSM> 2003ish, not exactly sure

<pratul> It was published on 4 Feb 2004

<Kumar> What provision for breaking change in existing 1.1 processor?

<MSM> Committment for additive changes only

<MSM> Loose-coupling means certain aspects of data of interest will be in other specs.

<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.

<MSM> Separation of concerns is strong justification. The guys in the other spec knew what they were doing.

Discussion of applying these principles from MSM to SML

<Kumar> What do other people think of relying on latest version of XML? To me, it sounds precarious.

<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.

<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.

<John> What if your flags are "1.0 strict," for example, how do you deal with this?

<MSM> A conforming xml 1.1 processor must support 1.0

<MSM> The implementation will have to note incompatibility with runtime options independent of SML

<MSM> Separate from violation of SML spec, of course.

<Pratul> How 1.0/1.1 supported should be up to my implementation to decide.

<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.

<John> If producer created sml-if of 1.0 and 1.1 documents how much do we want to constrain that?

<Kumar> If consumer is 1.0 only, it can reject it.

<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.

<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)).

<MSM> Schema does not have a signal about version

<MSM> You can tell if it is valid against a 1.0 or 1.1, of course.

<Scribe> Resolution: No objections to John's assertion above.

<MSM> Consensus on general principle here.

<John> What about specific XML 1.1 question? General principle - is that OK?

<Pratul> General principle includes relying on other specs. We specify a floor, but not a ceiling.

<John> For each specific case, we will choose a specific spec that will serve as a floor. Is anybody uncomfortable with this?

<Scribe> Resolution: Above resolved as per John.

<pratul> And conforming implementations must support the selected floor

<John> XML 1.0 / 1.1 decision. Are we satisfied with applying the general principle here?

<Kirk> We have to keep in mind future versions.

<Jim> I propose that we adopt XML 1.0 as the floor as a general principle unless there are specific issues later.

<Scribe> Resolution: XML 1.0 is the fixed floor.

<Marv> Propose we want to add the boiler plate encouraging implementors.

<MSM> W3C has specific rules for IP. Regarding references there is not a strict rule.

<Marv> This is ISO boilerplate that we saw on slide 17.

<Marv> That wording or something analogous.

<Sandy> We should wait until we agree on all references.

<MSM> We can adjust it later as necessary if we end up with a special case.

<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

<Scribe> 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

XML Schema 1.1 overview

<Scribe> 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 presentation of XML Schema 1.1

Sandy: There are 1.0 schemas that are no longer valid under 1.1. But people should not have been using the breaking structures.

<MSM> Schema wg (I think) will not go to rec pointing to something (IEEE floating point spec) 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 choosing 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

MSM on XPATH 2.0

Paul: ... Current minutes only being generated by rrsagent in pieces. MSM will help address this.

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: Philippe said IRI should be mandatory (I seem to remember)

MSM: Philippe 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 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

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?

<Sandy> ...

<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.

SML F2F Day 3

30 Aug 2007 (1 of 1: half day)

Attendees

Contents

Discussion of applying these principles from MSM to SML

XML Schema 1.1 overview

Sandy presentation of XML Schema 1.1

MSM on XPATH 2.0

Summary of Action Items