<scribe> Scribe: Zulah

<scribe> ScribeNick:Zulah

<scribe> ScribeNick: Zulah

<scribe> Meeting: SML

<scribe> Chair: John Arwe

Action Items

Review bugs with no keywords or target

<MSM> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5303

thanks

johnarwe: will update bug to hadproposal

zulah: would like more time to read the bug

pratul: requests that we close the bug on email

<MSM> My comment on the bug is:

<MSM> (Slightly pedantic editorial note:)

<MSM> For readers who think in terms of either the XML grammar or in terms of the

<MSM> XPath and XDM data models, the phrase 'the name sml:uri' can be misinterpreted

<MSM> as constraining just the prefix and local name, not the namespace and local

<MSM> name. I support the change, but suggest that the editors find some other phrasing

<MSM> to make clear that what we care about is the expanded name of the element, not

<MSM> its prefix.

Review and attempt to reach consensus on other non-editorial "hasProposal" bugs

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4687

ginny: this should be needsagreement and the new proposal is listed in comment #14 from Sandy

Kumar: schema bug is #5301

resolutions: move #4687 to editorial and make changes listed in comment #14 of 4687

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4644

Kumar: should we have restrictions on a derived type such that it has alteast the restrictions of the base type

<MSM> Proposal: we use the term "restriction invariant" for the proposition: it's not legal for an instance valid against a restriction to be invalid against the base type.

resolution: Sandy and MSM will type some appropriate words into IRC and then we will agree on them

<MSM> Proposal: 1 retain the existing rule allowing assertions only on global elements. 2 make an explicit rule that the restriction invariant must hold w.r.t. schematron assertions (as well as target* etc). 3 optionally observe that this means that a complex type R restricting a complex type B cannot replace a reference to a global element E in B with a local element E in R, if the global E has assertions.

<Sandy> 1. assertions can only be specified on global element declaraions

<Sandy> 2. assertions can only be specified on global complex type definitions

<Sandy> 3. assertions can be available on anonymous complex type (only via derivation/inheritance)

<Sandy> 4. assertions must satisfy complex type restriction rules (similar to target* constraints)

<Sandy> 5. if complex type T2 restricts complex type T1; T1 contains a reference to global element E with assertions; T2 contains a local E without assertions. This will be a restriction error.

<Sandy> 6. if compelx type T2 restricts complex type T1 and T1 has assertions, then those assertions are unioned with any other assertions specified on T2, if any.

<MSM> addendum: when complex type B has assertions, they are automatically copied to / inherited by any restriction R of B, and unioned with the assertions specified on the declaration for R.

johnarwe: does anyone have an issue with taking the text here in IRC and then marking the bug editorial?

resolution: #4644 will be marked editorial, the bug will be updated with the text

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4675

Same process as 4644. We will float a verbal proposal and then write that up.

<MSM> [highest level of guaranteed interop should be (1) uri scheme used, (2) no locator required for remote docs, and (3) whatever the third items was -- not just (1), I think?]

ginny: (1) remove level 1 and 2 naming in favor of more descriptive naming, (2) identity of reference scheme is identified with "must understand" sematics

johnarwe: if you were assuming fully consistent usage of reference schemes in every single reference fine - but if you step away from that you could get tangled up

Sandy: so the result is that you have a set of sets of what you coul d understand

johnarwe: reasons that an SML-IF consumer could give for not understanding a package: (1) locator (2) schema incomplete (3) understanding reference schemes

Kirk: assumes that there will be a scheme by which each reference scheme is identified

MSM: proposes qnames

Kirk: expresses desire for URIs in this case

Sandy" wants more clarification of changes being made

agreement to make clear conditions under which interop is guaranteed

<MSM> [I think the idea is to allow an SML-IF package to specify what the conditions for understanding it are, so I can tell by looking at the package whether I will be able to understand it, without having to have out-of-band negotiation between sender and receiver]

ginny: goal is to make it clear in the spec when interoperability is guaranteed and when it is not

pratul: equivalent to using the mandatory portions of the spec

MSM: would like a consumer to be able to tell whether or not a document can be understood.
... would like to see a simple set of keywords added to the transmission that works the way that a must understand header works

Kumar: is this at the beginning of the transmission to describe what will be coming later on?
... change of inconsistency between what is claimed and what is present. The only way a consumer can know if by processing the model. So it is about making a claim and whether you can trust it.

pratul: proposes a flag that indicate strictly conformant or not

<MSM> [I think that a Boolean flag provides less information than a list of the schemes required to understand the SML-IF package; I agree that consistency between declaration and package is not automatic]

discussion on why having means to understand reference scheme in document would be useful (there wass discussion of examples wheree it is difficult to identify the reference scheme)

proposal is to write into IRC what the proposal is

ginny: (1) expand the discussion of interopability in the sepcification
... (2) include a "must understand" for conformance

Kumar: spec says that a consumer can only process the schemes that it understands

<MSM> If we don't have a way to indicate what the requirements are for understanding an SML-IF package, then every package that's outside the narrowest compatibility group will require human to human negotiation between sender and receiver.

discussion about whether or not you could trust a "must understand" style designation

<MSM> [If we wish to make it possible to send conforming SML-IF packages that do not provide URI-scheme representations for all inter-document references, then I believe it would be useful to provide a sort of must--understand mechanism to allow / require an SML-IF package to indicate which reference schemes are actually in use (and possibly also declare the other relevant properties, like schema-completeness and use of locators).]

proposal to split the discussion into (1) text about levels of conformance and (2) syntax for capturing reference scheme being used

Zulah, Kirk, and MSM didn't object but leveled concern about ability to separate issue

johnarwe: proposal carries

discussion is on text for interoperability

proposal is now to (1) change the text and (2) change the names for level 1 and level 2 to be more descriptive

ginny: concerned about separating issues. Expressed concern about conformance characterization.

resolution: ginny will have proposed text and names by the end of the day

<MSM> [which bugs did John name?]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4637

<MSM> http://www.w3.org/TR/#Notes

<MSM> +1

Kirk: recommendation is to move all of the EPR work as a W3C notes

Valentina: could this me a non-normative appendix

question is whether the non-nonrmative stuff could be worked on after the due date

johnarwe: does anyone object to having Kirk's proposed text in the spec and having be normative (normative in the sense that if you are going to do an EPR scheme here is how you do it)

zulah: object

ginny" object

johnarwe: does anyone object to making the current proposal a separate workgroup note?

no objection

johnarwe: does anyone object to making it a non normative appendix?

zulah: object

ginny; object

johnarwe: we have concensus to have this be a note

resolution: mark bug as editorial to be written up as a work group note

<MSM> ACTION: MSM to make a new component for the EPR Note, in Bugzilla, once the text is out of the SML and SML IF specs and once there is a draft of the Note. [recorded in http://www.w3.org/2007/12/06-sml-minutes.html#action01]

<trackbot-ng> Created ACTION-154 - Make a new component for the EPR Note, in Bugzilla, once the text is out of the SML and SML IF specs and once there is a draft of the Note. [on Michael Sperberg-McQueen - due 2007-12-13].

valentina: suggests two bugs, one for the editorial work around the spec and another for the note

resolution: current bug for removal of EPR scheme from spec, and new bug to be opened about the creation of a note

<MSM> [time check]

johnarwe: takes case of 5106, 5242, and 4637

<pratul> I need to leave now - bye

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/but/bug/
Succeeded: s/location/locator required for/
Found Scribe: Zulah
Inferring ScribeNick: Zulah
Found ScribeNick: Zulah
Found ScribeNick: Zulah
Default Present: +1.610.277.aaaa, ginny, Kirk, Valentina, MSM, Zulah_Eckert, Sandy, johnarwe, pratul, Jim, [Microsoft]
Present: +1.610.277.aaaa ginny Kirk Valentina MSM Zulah_Eckert Sandy johnarwe pratul Jim [Microsoft]
Agenda: http://lists.w3.org/Archives/Public/public-sml/2007Dec/0051.html
Got date from IRC log name: 6 Dec 2007
Guessing minutes URL: http://www.w3.org/2007/12/06-sml-minutes.html
People with action items: msm

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.