W3C SML Teleconference of 2008-03-27

27 Mar 2008


See also: IRC log


Michael, Kumar, Pratul, Ginny, Sandy, Kirk, John, Julia, Zulah, Jim


Approval of previous meeting minutes

No objections noted.

Action Items

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

Bug 5341

Postponed to allow more time for review.

Bug 5283

Discussion still taking place on this bug

Bug 5298

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.

Bug 5518

<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'

Bug 5519

<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.

Bug 5520

<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

Bug 5527

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

Summary of Action Items

[End of minutes]

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