See also: IRC log
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5303
johnarwe: will update bug to hasproposal
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.
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 at least 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 complex 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 could 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?
... chance of inconsistency between what is claimed and what is
present. The only way a consumer can know is 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 was discussion of examples where it is difficult to identify the reference scheme)
proposal is to write into IRC what the proposal is
ginny: (1) expand the discussion
of interoperability in the specification
... (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 note
Valentina: could this be 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: objection
ginny: objection
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: objection
ginny: objection
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 care of 5106, 5242, and 4637
<pratul> I need to leave now - bye
Last Scribe Date Member Name Regrets pending 2007-08-30 Lipton, Paul until mid-December 2007 2007-11-08 Smith, Virginia 2007-11-12 Wilson, Kirk 2007-11-15 Lynn, James 2007-11-19 Valentina Popescu 2007-11-26 Boucher, Jordan 2007-11-29 Gao, Sandy 2007-12-03 Kumar, Pandit 2007-12-06 Eckert, Zulah Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH