SML WG Conf Call

31 Jul 2008

See also: IRC log


MSM, Kirk, Sandy, Kumar, Pratul, Ginny
John, James, Julia
Kumar Pandit


Approval of minutes from previous meeting(s)

resolution: minutes approved for 7/24 call.

Dates for the next F2F in Redmond

The CG has approved 10/27 ~ 10/29 instead of 10/28 ~ 10/30 as we had asked for.

Are people ok with the new dates?

Pratul: No one seems to object.

resolution: group approved the changed dates: 10/27~10/29. We will start at 1pm on 10/27 and end at 5pm on 10/29.

bug# 5543

Pratul: Does the schema spec require schema processors to expose DTD IDs?

msm: Although the schema spec does not specifically say it but they are expected to preserve the input infoset. Therefore most schema processors that I know preserve this info.

sandy: The infoset may be preserved by schema processors but they may not expose it through any API.

<MSM> SG: since DOM has only one gettype() method, if you have type info both from DTD and Schema, you only get one or the other

<MSM> SG: DOM3 says if you don't do XSD validiation, you get type info from the DTD, and otherwise you get it from the XSD validation

<MSM> [MSM: so you might get suboptimal results if the DTD and the XSD schema conflict.]

Kumar: .net schema processor does not make available DTD ID info if schema based validation is performed.

msm: There is no disagreement where no schema+dtd present or when both are absent.
... the controversial case is when both schema and dtd are present or when only dtd present.
... can we say that we will perform DTD based validation when no schema is present.

pratul: the SML spec makes no mention of DTD based validation.

kumar: My interpretation of the XML spec is that non-validating processors are not required to process IDs.

sandy: That is correct. They are not required to do full ID processing but they are required to normalize attribute values for which they need to know the type.

kumar: Regardless of whether underlying xml processors support IDs, the point is moot if a schema processor does not make available that info. Since most SML processors will be layered on top of a schema processor, this makes it hard to get to this info.

msm: if there is no schema and if dtd is present, would we perform schema validation or dtd validation?

kumar: my understanding is that we will perform schema validation.

pratul: when you say no schema documents, do you mean no schema in the entire model or no schema for one doc?

kumar: The majority case is where schemas will be present because we add SML constraints at schema level. We already seem to agree that schema based type info would override the dtd based id. Thus when schemas are present we can safely use schema-determined IDs. The only controversial case is when no schemas are present and only dtds are present. I believe that such cases are very few since we use xml schema to define sml constraints.
... given that we cover majority of cases and we are not preventing anyone from supporting the minority case, we have a fair chance of convincing Henry on our position.

pratul: do we know how prevalent is the use of DTDs?

msm: they are probably not used in web-services area but since they are defined in the XML spec, they have wider implementation support than any other schema language.

pratul: does the group want to try to convince Henry based on our discussion?

kumar: I will prepare a draft and circulate it within the members. when members agree, we can present our position to Henry.

sandy: there are 3 ways to recognize schema-determined IDs: 1) xpointer 2) xpath/xquery 3) DOM3 specs.

kumar: can we align with xpointer since we already use it for smlxpath1()?

msm: I prefer xpointer alignment.

resolution: align schema-determination of IDs with xpointer spec.

bug# 5797

kumar: in lax-wildcard mode, when the root element does not match a top-level element declaration and has no xsi:type, we will end up matching the root element against anyType. Can the schema processor stop at that point and not process any children?

msm: yes, schema 1.0 allows that. schema 1.1 requires the children to be processed in this situation.

kumar: since we align with schema 1.0, we may want to go with option described earlier.
... the proposal from msm as I understand it: If a schema is bound to an instance document, we perform strict-wildcard validation. If a schema is not bound to an instance document, we perform lax-wildcard validation. The SML spec does not define how a schema is bound an instance document.

<MSM> I would add: The SML spec should say explicitly that it does not specify how to bind schema-instance binding.

<MSM> A user who really really wants validation against a schema containing only the built-ins can always get it, by binding the instance to the schema corresponding to <xs:schema xmlns:xs="..."/>

modified proposal: If a schema is bound to an instance document, we perform strict-wildcard validation. If a schema is not bound to an instance document, no schema validation is performed. The SML spec mentions that it does not define how a schema is bound an instance document.

resolution: the proposal above was accepted by the group.
... mark editorial. needsReview after editorial changes.

<MSM> SG: should we make a new bug for IF, to make it possible to have an unbound instance document in IF? A: yes.

Summary of Action Items

[End of minutes]

Updated Scribe List

Last Scribe Date        Member Name         Regrets pending
2008-05-22              Lynn, James
2008-06-25              Smith, Virginia     9/4, 9/11
2008-07-10              McCarthy, Julia     7/31
2008-07-17              Gao, Sandy
2008-07-24              Wilson, Kirk
2008-07-31              Kumar, Pandit
Exempt                  Arwe, John          7/10 - 8/5 inclusive
Exempt                  Dublish, Pratul     8/28
Exempt                  MSM