See also: IRC log
RESOLUTION: WG approves 2008-07-10 minutes at http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0027/10-sml-minutes.html
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5542
WG: This bug currently has component = core. We clarified that this bug affects both Core and IF. Will change "component" to reflect it.
John's proposal (option 4): http://lists.w3.org/Archives/Public/public-sml/2008Jul/0019.html
Kumar: still not sure why we need to care about xml:base when schema doesn't require it.
Ginny: schema didn't have too
much to do with xml:base other than schema location, but the
locations themselves are not required.
... I did get confirmation that HP is comfortable with using
xml:base and has found xml:base support where needed.
<Kumar> [Definition:] Fully conforming processors are network-enabled processors which are not only both ·minimally conforming· and ·in conformance to the XML Representation of Schemas·, but which additionally must be capable of accessing schema documents from the World Wide Web according to Representation of Schemas on the World Wide Web (§2.7) and How schema definitions are located on the Web (§4.3.2). .
Kumar: are you sure that schema locations are not required to be processed? (see the above definition)
Ginny: don't think it's relevant.
<Kumar> http://www.w3.org/TR/xmlschema-1/#concepts-conformance
Kumar: not related to schema location. if these processors can fetch documents from the Web, shouldn't xml:base be used?
Sandy: to repeat MSM's argument. 2E is only supposed to fix errors in 1E. not referring to xml:base (not available when 1.0 was issued) was not an error, which is why 2E didn't include it.
Kumar: but does schema 1.1 support xml:base? if w3c really thinks xml:base should be used everywhere, schema should support it.
<Kumar> Kumar: If W3C really wanted xml:base to be used, they could have added the requirement to schema 1.0 2E spec stating that its omission in the 1E was an error.
Pratul: maybe whether schema requires xml:base shouldn't be our focus. we should focus on what's the best for our spec, our implementations, and migration of existing models.
Ginny: agree to what Pratul said
Kirk: agree too
Kumar: supporting xml:base has a direct impact on existing implementations.
Ginny: like to hear Kumar's opinion on John's option 4; and we need all parties, including Michael and John, to participate.
Pratul: John will be away for a few weeks. May not be able to wait for him. Michael is not here today. People here should try to reach agreement.
Kumar: this is a compromise that i'm willing to consider.
<Kumar> Kumar: the existing SML validator implementations are layered on top of XML schema processors. The schema processor themselves do not support xml:base because the XML schema spec does not require or recommend it. Because the underlying schema processor does not support it, the layer on top has to add that support.
Julia: Ginny's suggested change seems to be significant. It seems to change point 5 from optional to required.
Ginny: I need to check the spec. Consumers are not required to do much. It's validators that really need to support this. If all validators need to support "aliases", then that would imply that xml:base is also required.
Pratul: what does it mean for a producer to support xml:base.
Ginny/Kirk: you must be capable of producing xml:base, to ensure inter-op.
Kumar: making xml:base required
instead of optional in point 5 is a significant change. This is
different from aliases.
... a related issue. comment #2 in 5542 from Henry: there is
difference between requiring [base URI] and requiring
xml:base.
Ginny: what does it mean to refer to the [base URI] property?
Sandy: allows its value to be computed using different means, including from xml:base or other sources.
Ginny: during interchange model validation, are aliases required to be processed?
Kumar: yes
Ginny: if consumer support of xml:base is optional, then that consumer may not be able to process a model that makes use of xml:base.
Kumar: yes, as with any other optional features, like schema 1.1.
Ginny: think I can live with that. still want a statement about the future of smlif:baseURI. could be non-normative.
Kumar: point #1 says only allow smlif:baseURI in the model element. currently we allow it both at model level and document level.
Ginny: because, according to earlier discussion, existing models only use smlif:baseURI in <model>
Pratul: maybe we just remove point #1. Support <smlif:baseURI> is already optional.
Kumar: I can live with that, points 2-5.
Pratul: so proposal on the table: a) bullets 2-5 in John's email (option 4) and b) a statement that smlif:baseURI may be deprecated in future versions of the spec.
Julia: we could say "the intention of the authors of this spec is to deprecate this feature if a future version is introduced".
RESOLUTION: adopt the proposal a) bullets 2-5 in John's email (option 4) and b) a statement that "the intention of the authors of this spec is to deprecate this feature if a future version is introduced" for IF.
http://lists.w3.org/Archives/Public/public-sml/2008Jul/att-0002/20080625-sml-minutes.html#item10
Sandy: the above link is MSM's proposal. it covers Core.
Kumar: what does it mean by "using [base URI]"?
Sandy: similar to other infoset
properties (e.g. element name)
... we need to make sure Core and IF are consistent. if Core
only talks about [base URI] and IF only talks about
smlif:baseURI and xml:base, then readers may be confused. Need
to connect them.
... concretely, we use [base URI] in both Core and IF. In IF,
we additionally describe how [base URI] is computed, from
either smlif:baseURI or xml:base, whichever is supported by the
consumer.
Kumar: also need to describe how [base URI] is computed in Core: impl-defined, but need to be consistent with the 4 steps described by the relevant RFC.
Sandy: that would be correct, but may not be necessary. implied by the definition of the [base URI] property.
Kumar: is information from the 4 steps required to be made available? e.g. if xml:base appears in the document, but my processor doesn't make it available, then it may not end up in the [base URI] property.
Sandy: yes, that matches my understanding.
Ginny: we might have to say something about the case when both smlif:baseURI and xml:base appear in the IF document.
<pratul> Proposal
<pratul> In IF, we additionally describe how [base URI] is computed, from either smlif:baseURI or xml:base, whichever is supported by the consumer.
<pratul> In core, require the use of [base URI]
<pratul> and say that its computation is impl-defined, but need to be consistent with the 4 steps described by the relevant RFC.
RESOLUTION: on 5542, in addition to the resolution above on smlif:baseURI vs. xml:base, the WG agrees to the above proposal from Pratul.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5543
<pratul> <Sandy> because a) not all xml processors are *required* to expose DTD IDness, and b) schema IDs may or may not be recognized depending on whether you actually do schema validation.04 01the best we can do is probably to allow bare name, but makes its behavior impl-defined.
Pratul: what does impl-defined mean? can a processor just always return null?
Sandy: a little stronger. the feature is required and processors are expected to try their best to resolve it. e.g. if schema validation was performed, then schema ids should be recognized.
Kumar: agree. schema IDs are available in PSVI.
http://www.w3.org/TR/xpath-datamodel/#dm-is-id
Sandy: the above link (and other
places in the XDM spec) describes how IDs are recognized.
... in particular, sections 6.2.4 and 6.3.4 on schema IDs.
Kumar: this looks a little more complicated than what I thought. will need some time to look at this.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5797
Sandy: we were considering
"strict-wildcard" mode, but the concern was about models who
don't have schema documents, then most likely they would always be
marked not valid.
... possible solutions. a) when there is no schema document at
all, then use "lax-wildcard", otherwise "strict". or b) for
instances documents covered by at least one "schema binding",
use "strict"; if an instance is not covered by any "schema
binding", then use "lax".
... (a) is easy to specify, but doesn't cover all cases. (b)
also has a problem because instances that are not governed by
any schema binding is supposed to use the "default schema", so
using "lax" may not be appropriate.
Last Scribe Date Member Name Regrets pending 2008-05-22 Lynn, James 2008-06-23 Wilson, Kirk 2008-06-24 Kumar, Pandit 2008-06-25 Smith, Virginia 2008-07-10 McCarthy, Julia 2008-07-17 Gao, Sandy Exempt Arwe, John 7/10 - 8/5 inclusive Exempt Dublish, Pratul Exempt MSM Exempt PH