See also: IRC log
RESOLUTION: we have consensus to approve the proposal in comment #1; mark editorial; mark needsReview when fixed
<johnarwe_> Some editorial suggestions:
<johnarwe_> - tweak comma placement
<johnarwe_> - move (impl-defined) parenthetical to end of sentence
<johnarwe_> - change "should be read" to "to be read" or similar... want the sense of must, without using rfc2219 keywords like must or should.
RESOLUTION: Consensus is to approve the proposal with the above editorial tweaks; mark editorial; no needsReview necessary
MSM: what sense is it to have an
sml:acyclic attribute on an element whose type does not allow
an sml:ref attribute (e.g.., no xs:anyAttribute)
... it does not make sense
... model will be invalid if sml:ref is used in the
instance
Ginny: should keep paragraph together and move note to end
MSM: note contains example that
does not achieve its intent
... "does not choose to include a reference" should be
reworded
... author is not providing a target and signaling that the
absence of a target is not an error
<johnarwe_> It is a consequence of the preceding that this specification assigns no meaning to the sml:nilref attribute when it is used on an element that is not an SML reference. Model validators MAY choose to warn their invokers should they detect this condition in a document.
<johnarwe_> Note:
<johnarwe_> sml:nilref may be useful in the case where the schema author defines a complex type with sml:ref with a fixed value "true", but understands that not every instance will have a target.
<johnarwe_> one more time:
<johnarwe_> It is a consequence of the preceding that this specification assigns no meaning to the sml:nilref attribute when it is used on an element that is not an SML reference. Model validators MAY choose to warn their invokers should they detect this condition in a document.
<johnarwe_> Note:
<johnarwe_> sml:nilref may be useful in the case where the schema author defines a complex type specifying sml:ref with a fixed value of "true", but the instance author wants to signal that the absence of a target.
RESOLUTION: use the
above text for proposal 1 of Bug 5721
... change "can be valuable" to "can be useful" in proposal 2
text
MSM: confusing defining an sml
reference with recognizing an sml reference by sml:ref =
true
... an element type is not an sml reference; the instance is
the reference
<johnarwe_> Defining an element that is not always an SML reference with one of the above constraints can be useful because the decision about whether to include a constraint and the decision about whether to make the element an SML reference can be made independently - some choices made by the schema author, other choices made by the instance document author.
<MSM> The constraints described above can be useful even on element declarations whose instances are not necessarily / always SML references, because ...
<johnarwe_> The constraints described above can be useful even on element declarations whose instances are not necessarily SML references,
<johnarwe_> with one of the above constraints can be useful because the decision about whether to include a constraint and the decision about whether to make the element an SML reference can be made independently - some choices made by the schema author, other choices made by the instance document author.
<johnarwe_> The constraints described above can be useful even on element declarations whose instances are not necessarily SML references,
<johnarwe_> because the decision about whether to include a constraint and the decision about whether to make the element an SML reference can be made independently - some choices made by the schema author, other choices made by the instance document author.
RESOLUTION: Replace the text inserted by the fix with the above text for proposal 2; no needsReview necessary
Henry has approved the resolution of this bug.
Henry still prefers another title than "mapping from schema"
RESOLUTION: Henry and Sandy to discuss this and report back to the WG
RESOLUTION: Henry and Sandy to discuss this and report back to WG
RESOLUTION: reviewer satisfied
RESOLUTION: reviewer satisfied
Henry: need to get a signoff from David also
Henry approves the bug resolution
WG would like to rework the text change
<MSM> working paper: http://www.w3.org/XML/2008/06/sml-bug5542.xml
John's interpretation of MSM's proposal:
1. SML URI ref scheme: change base URI from impl-dependent to [base URI]
2. Add xml:base to <model> and <document>, replacing smlif:baseURI
3. [base URI] infoset property = source of base URI for absolutization
discussion of xml:base for documents referenced via locator element rather than inlined
MSM: xml:base must be explicitly allowed by the schema
if a document is 'located' rather than inlined and contains no xml:base then the xml:base on the <document> is used
Henry agrees with above proposal and would like to review the final spec prose
Henry is satisfied that the WG has reviewed 2557 and concluded that it does not meet our needs
RESOLUTION: reviewer satisfied
Discussion of whether schema processors expose xml:base property
<johnarwe_> wanted: MSM proposal: Add to 6.3.1 Mapping from schema, paragraph 3: For other schema
<johnarwe_> components, local-rules is empty.
Proposal: add to end of paragraph 3 in 6.3.1 "For other schema components, local-rules is empty."
<johnarwe_> tweak to new item 4: Otherwise, the value of the {rules} property is not effected by this specification.
<johnarwe_> proposed chg to 6.3.1 para 2: This specification assigns no meaning to sch:schema elements if they appear as items in any other location.
<johnarwe_> proposed append to bug 5636:
<johnarwe_> f2f consensus is to accept the changes with the following revisions:
<johnarwe_> Add to 6.3.1 Mapping from schema, paragraph 3: For other schema components, local-rules is empty.
<johnarwe_> change new item 4: Otherwise, the value of the {rules} property is not affected by this specification.
<johnarwe_> chg to 6.3.1 parag 2: This specification assigns no meaning to sch:schema elements if they appear as items in any other location.
RESOLUTION: fix per
above proposal;
... mark needsReview when done
RESOLUTION: resolve bug as WorksForMe
RESOLUTION: resolve as won't fix
<Kumar> question for Henry: in your comment #2 in bug# 5542 you said: "the right thing to do is a) require the use of the base URI property and b) encourage, if not mandate, XML Base support.". does this mean that one could use baseURI property without having to also support xml:base?
<ht> Yes, but that's sort of weak
<ht> The infoset spec. defines the semantics of the [base URI] property, and it covers things like getting the base URI right if you use a general entity to build an XML document from parts
<ht> If your parser does that much, getting xml:base support is pretty trivial
Kumar: A subset of Xml schema processors retrieve schema documents from the web. Even though such processors perform URI resolution and dereferencing, the xml schema spec does not require or even recommend such processors to use xml:base for converting schema locations from relative to absolute.
Kumar: The Xml schema spec does not require or recommend processors to expose the baseURI infoset property. This means that the applications that are built on top of xml schema processors cannot get this information from the schema processors.
Kumar: Given that the Microsoft SML validator is built on top of the .net xml schema processor, the proposal that SML must support [baseURI] property and xml:base adds undue implementation burden and potentially creates compatibility issues with existing models.
Discussion of John's 3 options for handling xml:base in the spec
base URI for URI resolution:
Rule: mutually exclusive
if smlif:baseURI exists, then xml:base ignored
else xml:base is the only way to get base URI from content
Option 1: smlif:baseURI optional + deprecated
- interop within MS = MS's choice
- interops MS/others = others' choice
- implementation cost = impl choice, based on desired interop scope (incl MS/not)
- spec complexity
- stmt of intent to remove smlif:baseURI next version
- [base URI] optional + SHOULD use xml:base
Option 2: smlif:baseuri required, deprecate in 2.0
- smlif:baseuri required, deprecate in 2.0
- interop with all = consequence of compliance
- more impl cost for all impls at future date
- spec complexity
- [base URI] required + SHOULD use xml:base
Option 3: [base URI] <-- xml:base only
- breaks existing MS instances
- more impl cost for current impls only
- spec simpler
Last Scribe Date Member Name Regrets pending 2008-04-17 McCarthy, Julia 2008-05-22 Lynn, James 2008-06-05 Gao, Sandy 2008-06-23 Wilson, Kirk 2008-06-24 Kumar, Pandit 2008-06-25 Smith, Virginia Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH