See also: IRC log
<scribe> scribe: Zulah
<scribe> scribenick: zeckert
<scribe> meeting: SML F2F day 3
<scribe> ACTION: james to create a proposal for #4992 [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action02]
<trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/2005/06/tracker/sml/
<scribe> ACTION: James to create a proposal for #4992 [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action03]
<trackbot-ng> Created ACTION-138 - Create a proposal for #4992 [on James Lynn - due 2007-10-24].
RESOLUTION: this moves to editorial
johnarwe: #7 is the only comment that may not be editorial
pratul: last sentence of "New consolidated text" appears to be redundant
johnarwe: if you are going to get rid of one (of the three sentences), keep the second
Ginny: reword sentence to remove the model author
Pratul: if a URI scheme is used, not every reference in a model has to be that URI scheme
Kumar: doesn't see why we should
allow multiple URI schemes to be supported within a model
... believes that this causes processor behavior to be
nondeterministic
Sandy: could have a situation where you use database keys and URIs because you have database items and files in a filesystem
Sandy: when you create a
reference scheme you have to define how to recognize it and how
to deref it. Proposed text doesn't address the former.
... new consolidated test change "an" in the last sentence to
"one and only one"
Ginny: remove second
sentence
... drop last paragraph
RESOLUTION: move to editorial and for "new consolidated test: (1) reword sentence to remove the model author, (2) remove the second sentence, (3) change "an" in the last sentence to "one and only one", and (4) remove the last paragraph.
Sandy: regarding comment #1 the group discussed this and concluded that model documents are allowed to use different reference schemes in a single model
Ginny: do we expect that this will change the spec in any way
Sandy: if we adopt the resolution then this is covered
johnarwe: could the new amended text be read such that it addresses Kumar's concern?
<ginny> The SML URI Scheme is based on the anyURI type defined in the XML schema specification [XML Schema Datatypes]. More precisely, for each SML reference in the model that is represented using the URI scheme, the reference MUST be represented using one and only one instance of the sml:uri global element declaration as a child of the
<ginny> reference element.
Ginny: thinks that this is taken care of by a bug that has been taken care of
RESOLUTION: this is
a duplicate of #4636, Ginny will remove this
... we will make #5133 dependent on #4636
Pratul: this is not a restriction of schematron, but rather of the original SML proposal
MSM: adequate resolution to bug would be inclusion of pointers to design rationale
Sandy: assertions are strongs and their meaning may be affected by namespaces
pratul: believes that this needs a proposal
<scribe> ACTION: Pratul #4644 will write a proposal [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action04]
<trackbot-ng> Created ACTION-139 - #4644 will write a proposal [on Pratul Dublish - due 2007-10-24].
RESOLUTION: moves to needs agreement, action to pratul to create a proposal
<scribe> ACTION: John Arwe to determine whether or not Intel wishes to remain a member of the WG and remind them that they have not been participating [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action05]
<trackbot-ng> Created ACTION-140 - Arwe to determine whether or not Intel wishes to remain a member of the WG and remind them that they have not been participating [on John Arwe - due 2007-10-24].
<ginny> Intent is to allow processors or applications that consume the error output to recognize specifically tagged data.
Resolution: move to editorial, reword such that Intent is to allow processors or applications that consume the error output to recognize specifically tagged data.
johnarwe: proposal on the table is to remove the text
Pratul: currently this is in the non normative text but uses the word must
Jim: leave in non normative section but not use the word "must"
MSM: it sounds like wording is wrong
Sandy: we may change the document and invalidate all of the signatures - it is possible that we have to change the document
MSM: Assuming that users may want to send signed docs and docs may or may not have to be changed it seems reasonable to provide guidance for how to deal with these situations. MSM proposes that this be moved to NeedsAgreement.
Pratul: Normative or non normative?
MSM: At this point, would like the group to have agreement, clarity
<scribe> ACTION: Kumar to provide a proposal for #4746 that includes providing guidance [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action06]
<trackbot-ng> Created ACTION-141 - Provide a proposal for #4746 that includes providing guidance [on Kumar Pandit - due 2007-10-24].
RESOLUTION: moved to NeedsAgreement and action to Kumar to create a proposal
johnarwe: thinks that this is
editorial
... choose a term for consistency (could be "Schematron Rule
documents", "rule documents", or "documents" - then make sure
that the term is defined
RESOLUTION: moved to editorial and choose a term for consistency (could be "Schematron Rule documents", "rule documents", or "documents" - then make sure that the term is defined
Ginny: this is 3.4.6 in SML-IF
<Valentina> thinks that 4748 is dependant on 5169 and should be marked as such in bugzilla
johnarwe: bug is still relevant. Last sentence of 3.4.6. says "the element" but in SML-IF any given fragment could resolve to (1) 0 elements, (2) 1 element, (3) or more elements. And each of these cases needs to be covered.
Ginny: these are IF inter-document references
Pratul: IF does not care what you get. A validating consumer may care, but IF doesn't care about the three cases.
johnarwe: proposal is that we don't care about the three cases. But this is not yet a coherent proposal.
Ginny: in the context of SML-IF,
would we fix up a fragment? Thinks not and so we don't care
about the fragment because we aren't going to resolve it.
... we could say that we are only concerned with the URI and
not the fragment or we could remove the entire section?
Kumar: is there a case where we will have a fragment for a non sml reference?
Ginny: still don't have definition of inter-document references
johnarwe: could make this
dependent on the inter-document reference bugs (#5120,#5171,
#5181, #5201) because until we know what an inter-document
reference is we won't know how to deal with this bug
... proposal is to make #4755 dependent on #5120
RESOLUTION: make #4755 dependent on #5120, and mark as needs agreement
Zulah: there was some discussion in the original group
Pratul: by HP
MSM: What would it mean for an instance document to be a root document for the model? Is this well defined?
johnarwe: what is the semantic meaning of saying that something is root?
MSM: hearing two things (1) a root is a place that you might start and this is highly operational or (2) a particular location in a graph and this is structural
Jim: do not mark any documents in the model (won't fix this bug)
Zulah: concerend that HP strongly wanted this pre-proposal but defers to HP's opinion now
RESOLUTION: #4769 will be moved to Won't fix
johnarwe: intent was to allow
other things to be reused for example role bindings
... has original notes and proposal (done with Bryan Murray)
and will take the action item to create proposal
<scribe> ACTION: John Arwe will create a proposal for #4770 [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action07]
<trackbot-ng> Created ACTION-142 - Arwe will create a proposal for #4770 [on John Arwe - due 2007-10-24].
RESOLUTION: Move to needs agreement, John Arwe has an action item to create a proposal
johnarwe: this was a question from pre-submission. We have rule bindings we don't have a convenient way in the SML syntax to refer to rule bindings. Perhaps these could be refered to by naming.
Sandy: The schema for schemas has an ID attribute. This is not used when processing instance document. We could do something similar here.
johnarwe: proposes that we do nothing about this. People can put ID attributes on if they want. Because we have no intent to use this for validation why clutter up the spec. So the proposal is Won'tFix.
MSM: and note in the resolution that xml:id exists (or any other qualified attribute).
RESOLUTION: #4771 move to Won'tFix status
johnarwe: structured output when Schematron assertions fail to be satisfied. Currently, we allow a localization ID, but we don't allhow keyword values to be substituted into the string. There was some pre-submission discussion about allowing this substitution.
Pratul: Schematron has the ability to put values inside error messages. He thinks that there is a proposal from the original group.
Valentina: will speak to Harm as he was the person who proposed this
<scribe> ACTION: Valentina to create proposal [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action08]
<trackbot-ng> Created ACTION-143 - Create proposal [on Valentina Popescu - due 2007-10-24].
RESOLUTION: move this to NeedsAgreement and assign action to Valentina to create a proposal based on the original groups discussion/proposal
MSM: If you read literature on formal specifications, in a number of places people advise that if you want reliable specs, one of the easiest ways to do that is to write them in two languages. Some organizations due this (e.g., issuing simultaneously in English and French). If you do this one after the other, you find alot of bugs. Given this, he thinks that perhaps we should be working...
johnarwe: discussion at Toronto F2F. If normative text and normative schema disagree, what do you do. Recollection is that Pratul leaned towards text wins, and MSM had a different position
MSM: Either the group made a
clear decision and there is a typo which calls for issuing an
errata or there was disagreement
... if the working group has a failure due to disagreement then
the group should fix it. Working groups have a certain amount
of after life to deal with errors against the spec.
Pratul: Small part of the spec is XSD. Favors normative text.
MSM: This overlap is where there can be a contradiction in the spec.
Zulah: How does the W3C normally deal with this issue?
MSM: No W3C wide policy. Feels that more groups choose formal spec over prose.
Pratul: Modifies his proposal such that in the area where the XSD and the normative spec overlap, given that the schema is more formal, the schema wins.
Jim: doesn't capture case where prose is clear and unambiguous and the XSD is broken. Proposes that you only take this proposal in the case that there are ambiguities in the text.
Zulah: Why does a group have to state how they will deal with issues and deal with them on a case by case basis?
MSM: This is one of the proposals on the table.
Kumar: Feels that the spec if more likely to be correct with respect to what we decided.
johnarwe: feels that we will find incentive in the choice that we make up front on this issue.
Ginny: thinks that the fact that
the prose is what we are working on now might lead us to
believe that the spec would ultimately be more correct
... differently. Specifically that we create the prose and
schema concurrently.
MSM: so proposal is to focus more on schema, restructure that part of the document.
Some discussion on what constitutes an errata vs. a spec revision.No specific W3C process/guidance on this.
MSM: in practice, doesn't think that the two interpretations will be different. That is, the only errata that you will get agreement on is one that changes the text in a way that does not move existing implementations from compliant to non-compliant.
johnarwe: effect on user if we don't choose one of these options is that a user will be forced to make a decision during implementation which may change after the group resolves the issue.
We now have four proposals (1) text wins, (2) XSD wins, (3) neither wins, (4) (tie breaker) a mix where something works so that people can continue implementing without waiting for the group and (5) XSD wins, then text wins.
johnarwe: first proposal, do we need a tie breaker? (4) above
we did not have consensus
RESOLUTION: #4776 moves to NeedsAgreement
Kumar: proposes that we discuss this after last call because it is a philosophical discussion
MSM: thinks that if we do this that this might change how people would review the spec
<scribe> ACTION: Michael to keep the discussion about #4776 going in email so that eventually we come to some agreement [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action09]
<trackbot-ng> Created ACTION-144 - Keep the discussion about #4776 going in email so that eventually we come to some agreement [on Michael Sperberg-McQueen - due 2007-10-24].
RESOLUTION: move to needs agreement and make dependent on #5120
<Sandy> URI-reference is used to denote the most common usage of a resource
<Sandy> identifier.
<Sandy> A URI-reference is either a URI or a relative reference.
MSM: We should carefully align with 3986 we should review the latest version. Where the RFC defines terms that are what we wanted to say, we should use them, and where this is not the case, we should use other terms.
Sandy's text (above) is from 3986
Sandy: suggests that we change relative URI to relative reference.
johnarwe: points out that where we cannot have fragments we need to use absolute references
RESOLUTION: move to editorial, any changes need review, take the following approach (1) replace URI with URI reference, (2) replace relative URI with relative reference, (3) insert absolute whenever we mean absolute URI.
<ginny> Note, editor should be careful to create a diff document for the changes for this bug and only the changes for this bug!
<ginny> from IRC - RESOLUTION: move to editorial, any changes need review, take the following approach (1) replace URI with URI reference, (2) replace relative URI with relative reference, (3) insert absolute whenever we mean absolute URI.
<ginny> If any URI usage is unclear or not covered above, come back to the group (preferably with proposal) to decide correct term.
<Kumar> scribe: Kumar
ginny: this will be rewritten based on the cycle proposal
agreed editorial
john: I propose that we should not fix it. we will come back to it if people ask for it.
<scribe> ACTION: virginia to investigate bug# 4811 and come back with proposal [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action10]
<trackbot-ng> Created ACTION-145 - Investigate bug# 4811 and come back with proposal [on Virginia Smith - due 2007-10-24].
<johnarwe> 4811 needs agreement
consensus: mark 4894 as dependent on 4639
sandy: for michael's proposal to work we need xpath 2
msm: explains why this can be done with xpath 1
sandy: xpath requires that a specific set of functions must be supported. if we directly refer to xpath spec it may be confusing since we allow only deref() fn
pratul: since xsd id constraint selector does not allow arbitrary xpath functions, we defined sml selector this way
kumar: what is wrong with using BNF?
msm: explains. feels this works
better way in the long run.
... I propose that we remove BNF, describe the same thing in
words.
consensus: won't fix
consensus: this is covered by the Ref proposal. mark editorial.
msm: this is already covered by our discussion yesterday. level 2 conformance addresses this.
pratul: since this is already addressed, I propose that we should not fix this.
msm: since we are already thinking of creating 2 levels of sml-if conformance, we may as well add to the level 2 requirement that documentURI be mandatory.
pratul: this may put undue burden on some implementations since they may want to support sml:uri but not documentURI
consensus: mark as needsAgreement
<scribe> ACTION: michael to create proposal for 4994 [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action11]
<trackbot-ng> Created ACTION-146 - Create proposal for 4994 [on Michael Sperberg-McQueen - due 2007-10-24].
<Sandy> Proposal and example for 4995: http://lists.w3.org/Archives/Public/public-sml/2007Oct/att-0083/Proposal_for_Allowing_smlkeyref.doc
kumar: explains how the end goal of 4995 can be achieved without changing existing spec.
sandy: this is restrictive since it requires one to know the structure of the targetted key constraint element.
kumar: shows how this knowledge is required in the proposal where 'scope' attribute is added.
<scribe> ACTION: Kumar to add Sandy's original example and the updated example to the bug text [recorded in http://www.w3.org/2007/10/17-sml-minutes.html#action12]
<trackbot-ng> Created ACTION-147 - Add Sandy's original example and the updated example to the bug text [on Kumar Pandit - due 2007-10-24].
consensus: we will add one more example for keyref. The example will be supplied by Sandy.
sandy: We should not define how a producer should produce sml-if documents. the actual process may be implementation dependent. we should only define how the end-result looks like.
... we do not have to define how de-mangling should be performed at all since we can treat the mangled dtd as applying to all docs.
msm: not comfortable about not defining de-mangling algorithm
... defines sml-if as a way to transmit a model as an xml document.
jim: proposes that we do not require a producer to always produce mangled header dtd. a producer may choose to produce standalone documents before creating sml-if. another producer may create the mangled dtd.
msm: is not comfortable with the idea.
kumar: what type of info is provided by the dtd
msm: 4 categories of items (listed in his proposal email)
john: is cosmos implemenation required to support a model with dtds in it?
msm: it should just work since all xml processors will accept it.
john: if it doesn't work for some reason, is cosmos in violation of compliance?
msm: if the spec says that sml-if is simply an xml document (without any more qualification) then yes cosmos will be in violation.
sandy: here is my proposal:
... for producers: (SHOULD or MUST) (normalize to standalone or base64 encode)
... for consumers: 1. if document/data/base64 found => unpack and use as dtd 2. else use same dtd for all instances
Last Scribe Date Member Name Regrets pending 200y-mm-dd Vijay Tewari 2007-08-30 Wilson, Kirk 2007-08-30 Lipton, Paul 2007-09-06 Boucher, Jordan 2007-09-20 Lynn, James 2007-09-27 Gao, Sandy 2007-10-04 Smith, Virginia 2007-10-16 Valentina Popescu 2007-10-15 Waschke, Marvin 2007-10-17 Eckert, Zulah 2007-10-17 Kumar, Pandit 2007-06-12 Tabbara, Bassam Until 10/30/07 Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH