W3C SML Teleconference of 2008-07-03 -- 03 Jul 2008

Approval of minutes from previous meeting(s)

<johnarwe_> 6/23 minutes from Kirk: http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0004/20080623-sml-minutes.html

<johnarwe_> 6/24 http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0003/20080624-minutes.htm

<johnarwe_> 6/25 http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0002/20080625-sml-minutes.html

RESOLUTION: approve 2008-06-23~25 F2F meetings. (See links above.)

7/10 call

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.

5542 How are SML URIs absolutized

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

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.

<Kumar> http://www.w3.org/TR/xmlschema-1/

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 inter-op.
... 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 xml:base.
... 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.

5519 Relationship between SML model validity and XSD validity assessment

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

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.

5797 SML validity appeal to schema-validity is underspecified

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

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.

MSM: yes

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 are available.
... 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 lax-wildcard mode.
... 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.

5680 fix errors in schematron variable substitution support text & example

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

John: this is about changes to non-normative text, so we don't need to resolve it for the second LC draft.

Bugs that need to be resolved to get to 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

W3C SML Teleconference of 2008-07-03

03 Jul 2008

Attendees

Contents