See also: IRC log
<johnarwe_> 6/23 minutes from Kirk: http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0004/20080623-sml-minutes.html
RESOLUTION: approve 2008-06-23~25 F2F meetings. (See links above.)
Pratul: Pratul and John won't be able to attend. Need a chair for this meeting.
MSM: won't attend either.
RESOLUTION: Jim will be the acting chair for the July 10 telecon. John will prepare the agenda.
John: Kumar was going to research MS implementation
<pratul> 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.
<pratul> 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.
<pratul> 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.
Kumar: development cost is one aspect; the others are as raised during the F2F. (See the above text pasted by Pratul.)
MSM: can you clarify on the "schema spec" part? schema doesn't define an API, so no place in schema can be read as requiring any recalculation.
MSM: schema spec doesn't
encourage or discourage xml:base (xml:base didn't exist when
schema 1.0 first edition was released)
... but that should not be used to draw conclusions on whether schema thinks xml:base is important or not.
Pratul: wondering what makes it important for SML to support xml:base, given that schema doesn't.
<Jim> Ginny has asked to delay the decision on this bug for another week. HP has concerns regarding xml:base support.
MSM: this issue was not raised
against schema. if it was, then it would have been properly
dealt with. it is raised against SML. it provides better
... and solves the common problem (resolving relative URIs) in a standard way.
Pratul: agree to that argument, but it seems that xml:base hasn't had wide support in the XML community.
<pratul> Jim; Can u articulate HP's concerns re xml:base support?
Kumar: about implementations,
Microsoft XML processors (MSXML or .NET) don't have support for
... about the spec, I can understand why 1.0 1E didn't include xml:base, but 2E didn't include it either.
MSM: not including a reference to xml:base in 1E is not an error (because it was not available), which is why it wasn't included as an erratum to 1.0.
Kumar: people can read that to mean that it was not viewed as important enough to fix.
MSM: I don't agree.
Pratul: no one has raised the
xml:base issue to the schema spec, is that an indication that
people don't think xml:base is important?
... don't see consensus, also given that HP is not ready. maybe we should defer.
Kumar: don't oppose xml:base in principle, may be OK to include in a future version. Now it's very late to add this to existing SML processors. if we had talked about this a year ago, the result could have been different.
Kirk: the WG discussed this on June 25 (F2F) and said "WG would like to rework the text change".
MSM: suggest to move the first note (in section 8) out of the numbered list, and put it after the existing note.
RESOLUTION: make additional change suggested by MSM (see above) to 5519, mark the bug as editorial, no need to review.
Kumar: as I understand it. element-driven, type-driven, strict wildcard, and lax wildcard. which ones are common? which ones are widely supported?
MSM: schema 1.0 doesn't mandate any one of them. it can start with any mode, and start anywhere.
<johnarwe_> does schema 1.1 make any stronger stmt about this than 1.0?
Kumar: for SML, we need to always start from the root elements. how to start the type-driven validation?
MSM: we could, in IF, specify
element declaration or type definition to use to start
validation; that would require many changes. it'd be simpler to
specify wildcard-driven validation.
... element driven is useful. e.g. for HTML, <br/> is valid if wildcard-driven modes are used, but it's not a good HTML document.
Kumar: i can look at the root element name, find the corresponding element declaration, then start element-driven validation?
Sandy: element-driven itself requires the root element to match the declaration. what you described works, but wouldn't be very different from wildcard-driven modes.
Kumar: element-driven and type-driven requires additional metadata. when none is specified, then wildcard-driven is the natural choice.
Kumar: what modes does COSMOS support?
John: COSMOS uses Xerces as it's schema processor, which, from what I heard, supports all 4 modes.
Sandy: want to allow cases where, for example, layered spec can specify a validation mode that's different from the default specified in SML. it's important to not forbid that.
MSM: a concrete example, if a set
of HTML pages are transmitted as SML-IF, then it may be
desirable to be able to specify that (certain) root elements
must be <html>.
... to properly support it in IF, we may need to modify IF metadata to support element/type driven validation.
<johnarwe_> A less monolithic approach would be layering: SML allows type-driven validation against a designated type (by being silent about it). A second spec, Fred, defines markup that fits into smlif's extensibility points (xs:any etc) to add the requisite metadata.
<johnarwe_> I think that's the kind of layering Sandy was alluding to
John: slightly different scenario in terms of spec layering. (see above text from John)
Kumar: need clarification regarding element-driven and wildcard-driven; also strict-wildcard and lax-wildcard modes.
MSM: "select an element declaration based on root name, then use that for element-driven validation" is essentially how wildcard-driven mode works.
<johnarwe_> editors draft, sml, 8: A conforming SML model is valid if and only if it satisfies all of the following conditions:
MSM: the same PSVI is produced for strict/lax wildcard modes. strict-wildcard mode is an indication to the schema processor or receiving application to treat the input as "bad" if the root can't be strictly validated.
Kumar: is it OK for us to require strict-wildcard mode?
Sandy: that means if a model has no schema document, then most likely the mode would not be marked "valid".
MSM: problem with lax-wildcard is
that it's possible to miss certain errors, e.g. a typo in a
root element name.
... but another case is that if all my constraints are in Schematron rule documents, then I can't make the model valid.
John: I think making an interchange model consisting only of instance documents (with or without Schematron) automatically invalid violates the principle of least surprise, although I can well imagine the error cases MSM describes being problematic. Yu Chen is not here, but in his current implementation the most common case is an SML model with no schemas. (1) Not every instance document even has (or needs) a schema (2) in some cases (WSDL) a schema exists, but he doesn't need to carry it around he can quite safely refer to it. Maybe we need something more complicated than a single behavior to get something useful and usable...e.g. if schema bindings exist, strict, else lax.
John: or maybe if count(schema doc) = 0, then lax; otherwise strict
Kumar: maybe in SML, we make the
behavior implementation-defined when not all schema components
... in IF, schemaComplete can be used to indicate whether all components are available.
MSM: back to the spec layering
issue, normally "fred validity" (layered on top of SML) should
be a subset of "sml validity", so maybe sml should really use
... For IF, it is also SML validation, so it can't produce a result different from SML.
... That is, we need to choose between "fred validity != sml validity" or introducing metadata in IF to support other validation modes.
Kumar: lax-wildcard may not produce what users expect.
MSM: agreed. it's what most schema users expect; but still concerned about cases where only schematron is used in the model.
John: this is about changes to non-normative text, so we don't need to resolve it for the second LC draft.
Pratul: 5542 and 5797
John: and possibly barename support (the corresponding bug 5543 was closed)
Kumar: Henry was going to talk to his colleague about infoset ID property
Pratul: add a comment in the bug to indicate that Henry will come back with more information. Don't reopen it.
<johnarwe_> please log my regrets for 7/10-8/5 inclusive in the scribe list
Last Scribe Date Member Name Regrets pending 2008-05-22 Lynn, James 2008-06-19 McCarthy, Julia 2008-06-23 Wilson, Kirk 2008-06-24 Kumar, Pandit 2008-06-25 Smith, Virginia 2008-07-03 Gao, Sandy Exempt Arwe, John 7/10 - 8/5 inclusive Exempt Dublish, Pratul Exempt MSM Exempt PH