See also: IRC log
No objections noted.
no action items completed
<MSM> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5580
dependent on bug 5580
RESOLUTION: proposal approved; mark as editorial
Pratul: Based on resolution of bug 5580, we should mark as won't fix and append an explanation
Sandy: bug 5580 only changes URI reference in the URI scheme; there are other references in the spec
John: 4.3, 3b; 4.3.1, paragraph2
Discussion of rfc 2396 vs 3986
Sandy: Does MSM's proposal mean we remove all references to URI references not just in URI scheme
<JA> ex 1: sml, lc, 4.3 3b
<JA> ex 2: sml, lc, 4.3.1 1 para 2
MSM: revise proposal to say we think we do reference 3986; if that was true in the version you reviewed, that is no longer true.
<JA> sml spec does not have the string "media type" anywhere
MSM: look at what XInclude does with 'media type'
kumar: is there an rfc that
specifies fragment identifiers for xml media type
... 3023 does not define any syntax for xml media type
<JA> 3023 has NOT been superseded
<Kumar> 5. Fragment Identifiers
<Kumar> Section 4.1 of [RFC2396] notes that the semantics of a fragment
<Kumar> identifier (the part of a URI after a "#") is a property of the data
<Kumar> resulting from a retrieval action, and that the format and
<Kumar> interpretation of fragment identifiers is dependent on the media type
<Kumar> of the retrieval result.
<Kumar> As of today, no established specifications define identifiers for XML
<Kumar> media types. However, a working draft published by W3C, namely "XML
<Kumar> Pointer Language (XPointer)", attempts to define fragment identifiers
<Kumar> for text/xml and application/xml. The current specification for
<Kumar> XPointer is available at http://www.w3.org/TR/xptr.
MSM: noone supports all URIs;
most specify what they support
... support for only 1 xpointer scheme is not overriding the
semantics
Pratul: use MSM's initial proposal
<Kumar> Our response:
<Kumar> [1]
<Kumar> The definition of the SML URI scheme is based on xs:anyURI as defined by XML schema 1.0 specification (which depends on RFC 2396 & RFC 2732). This is why we do not specifically refer to RFC 3986 in the definition of SML URI scheme.
<Kumar> [2]
<Kumar> The SML WG believes that the specification does not override any RFC mandated URI semantics. Can you please clarify what part of the specification overrides the RFC ?
Pratul: suggest mention specific rfc in #2
RESOLUTION: Paste the above response - [1] and [2] - specified by Kumar into bug asking for clarification, and also refer to the resolution of bug 5580. Mark bug 'decided'.
RESOLUTION: fix per comment #2; mark as editorial
Postponed to allow more time for review.
Discussion still taking place on this bug
Proposal is to use SML URI Reference scheme
<MSM> maybe 'method' ?
<JA> strategy...
<JA> whatever
<MSM> pattern, form, formula, fred
<JA> philosophy
RESOLUTION: Use "SML URI Reference scheme"; mark editorial. If someone comes up with a better name later we can reopen.
<JA> in 5513, might want to point to the other bug we resolved today where we ack the ability to default sml:ref
<MSM> Possible response on 5518:
<MSM> There are answers on at least two levels.
<MSM> First, the ability to attach assertions to either elements or types is
<MSM> intrinsically part of Schematron, and should be overridden only with
<MSM> good reason.
<MSM> Second, we believe there is good reason for allowing assertions on
<MSM> both elements and types. Our experience is that some vocabulary
<MSM> designers work in a type-centered way, some in an element-centered
<MSM> way, and many in ways spread out along the scale. Restriction of
<MSM> functionality to types, and not allowing it on elements, favors one
<MSM> style of vocabulary design over the others; we are not certain,
<MSM> however, that type-centered design is the only style that needs to be
<MSM> supported.
<MSM> The same issue informs the SML design with regard to targetType, etc.
RESOLUTION: Paste paragraph above starting with "Second" into bug as working group response along with 'official response template'
<JA> to MSM: Henry had pre-LC, we made the chg to declarative in LC
RESOLUTION: working group response is that we fixed this in the Last Call draft; mark as 'decided'. Henry should get back to us if he reviews LC and disagrees.
<MSM> [For the record, I recorded my thoughts on this topic in two blog posts at http://people.w3.org/~cmsmcq/blog/?p=42 and http://people.w3.org/~cmsmcq/blog/?p=43]
MSM: XML serialization is one representation of an infoset
<MSM> [I should point out, of course, if it's not already obvious, that on this topic I am not speaking for the XML Schema WG. Sandy may have other views on the matter, and on whether the XSD decision to allow 'infosets' as input instead of 'XML' has had good or bad effects.]
<JA> is this not functionally equivalent to saying "let the market decide" if you are [usefully, in the eyes of users] compliant? i.e. that the common understanding of "xml document" will in practice rule the day, and it is a fool's errand to attempt to cover all the alternatives?
Postponing this bug for later discussion
<MSM> [JA, by "this" do you mean "the proposal in bug 5520"? or "the proposal to decline the suggestion in 5520"?]
<JA> I meant MSM's discussion around what is provable wrt a given impl
Kumar: namespace is optional because the function must be from a given namespace; nothing else is allowed
<MSM> [For the record, Michael Kay's book on XSLT 1.0 says (p. 452) "extension functions provided by ... third parties should always be in a different namespace and will need to have a namespace prefix when called."]
Pratul: dropping it completely might be cleaner approach if required namespace is ugly
Kumar: keep it the way it is or, if causing problems, make it mandatory
<Kumar> http://www.w3.org/TR/1999/REC-xpath-19991116#NT-FunctionName
Postponed for further discussion
Last Scribe Date Member Name Regrets pending 2008-01-22 Eckert, Zulah 2008-02-07 Lynn, James 2008-02-14 McCarthy, Julia 2008-02-21 Kumar, Pandit 2008-03-06 Boucher, Jordan 2008-03-13 Gao, Sandy 2008-03-20 Wilson, Kirk 2008-03-27 Smith, Virginia Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH