- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Mon, 11 Apr 2005 09:33:10 -0400
- To: <public-xml-core-wg@w3.org>
We have an XML Core WG phone call scheduled for Wednesday, April 13, from 08:00-09:00 Pacific time aka 11:00-12:00 Eastern time aka 15:00-16:00 UTC 16:00-17:00 in Ireland and the UK 17:00-18:00 in middle (most of) Europe on the Zakim W3C Bridge, +1 617 761 6200, passcode 9652#. We also use IRC channel #xmlcore on irc.w3.org:6665 . See the XML Core group page [1] for pointers to current documents and other information. If you have additions to the agenda, please email them to the WG list before the start of the telcon. Please also review our group page's task list [2] for accuracy and completeness and be prepared to amend if necessary and accept it at the beginning of the call. Agenda ====== 1. Accepting the minutes from the last telcon [3] and the current task status [2] (have any questions, comments, or corrections ready by the beginning of the call). 2. Miscellaneous administrivia and document reviews. The new XML Core WG charter has been approved. The Call for Participation is out, and everyone on the WG has to have their AC rep submit their name as a member in the rechartered WG within the next 45 days: http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0006 The WG reviewed the Binary XML documents: http://www.w3.org/TR/2005/WD-xbc-measurement-20050224/ http://www.w3.org/TR/2005/WD-xbc-properties-20050224/ http://www.w3.org/TR/2005/WD-xbc-use-cases-20050224/ Norm sent some comments: http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0046 Dmitry sent his comments at: http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0009 Lew sent his comments at: http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0007 Both Lew and Dmitry think Binary XML is an important issue and are mostly positive about doing something in this area. Norm reviewed some of the documents and had some serious problems with the presentation of some of the documents as well as with some of the technical comments. He is not convinced that it makes sense to standardize binary XML at this point. Since the Binary WG is closed, our comments would mostly be for whatever effort comes next, and since we don't have strong consensus comments, I propose we don't try to send in anything as a WG comment at this time. Richard reviewed the XPath 2.0/XQuery 1.0 Data Model document that is at: http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/ Richard's review is at: http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0014 3. XLink update. Our WG Note "Extending XLink 1.0" has been published: http://www.w3.org/TR/2005/NOTE-xlink10-ext-20050127/ A charter modification has gone to the AC: http://lists.w3.org/Archives/Member/w3c-ac-members/2005JanMar/0036 While we aren't quite chartered for this yet, we did discuss it some at our f2f: http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xlink Norm made a pass at XLink 1.1 at http://www.w3.org/XML/Group/2004/xmlcore/xlink11/ with a diff (from 1.0) at http://www.w3.org/XML/Group/2004/xmlcore/xlink11/Overview-diff.html 4. XML errata. The published 1.0 errata document is [8], the published 1.1 errata document is [9], and the NEW PUBLIC Potential Errata (PE) document is [7]. See the discussion of IRIs and the "MAY" paragraph under item 5. Namespaces in XML below (which actually occurred during our f2f under the XLink discussion). We need to make some IRI related errata to XML 1.0 and 1.1 (for system ids). Note this does NOT mean that we would change the reference to 2396 to now be 3986 because that could imply other changes. ACTION to Richard: Draft wording for the erratum to XML 1.0 and 1.1 updating the IRI wording (and referencing the MAY paragraph). We had a question about the XML Test Suite arise; see http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0037 Awaiting response from Richard. 5. Namespaces in XML. Richard suggested we take NS 1.1 and revert the two substantive changes (IRI and undeclared namespaces) to create NS 1.0 2nd Ed. The WG has consensus to do that, and we got approval from the team to do so. Ongoing ACTION to Richard: Produce a draft for NS1.0 2nd Ed. We note that the IRI spec is now finished-RFC 3987-so we have to issue an erratum for NS 1.1 for this. We discussed some details of this under the XLink discussion: http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#xlink Briefly, 3987 does have some wording (the "MAY" paragraph) about what used to be called unwise characters. For the NS 1.1 erratum, the MAY paragraph doesn't apply since namespace names cannot have the unwise characters. (The MAY paragraph will be needed for XML 1.* system identifiers.) ACTION to Richard: Process an erratum to NS 1.1 to refer to RFC 3987: http://www.ietf.org/rfc/rfc3987.txt 6. Xinclude Rec was published 2004 December 30 at: http://www.w3.org/TR/2004/REC-xinclude-20041220/ Our XInclude potential errata document is at: http://www.w3.org/XML/2005/01/proposed-xinclude-errata See http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0029 for the latest status of the open PEs. PEX1 Fatal XInclude errors in unactivated fallbacks --------------------------------------------------- We will add a paragraph to "Section 4.4 Fallback Behavior" about how there are no fatal errors relating to fallback-both errors within fallback elements and errors due to the wrong number of fallback elements-unless there is a resource error with the xinclude element surround this(these) fallback element(s). We will also add something after the third sentence of section 3.2 to this effect. ACTION to ???: Suggest actual wording. PEX2 URI or IRI errors handling ------------------------------- There will be no change to the spec. We don't expect implementors of XInclude to implement IRI processing, so whatever ends up happening with respect to IRIs isn't really the fault of the XInclude processor. However, we don't want to license such behavior, so we don't want to change our current wording here. ACTION to ???: Reply to the commentor. PEX3 What is an error (subcase on accept attribute value) -------------------------------------------------------- Can we close this as being a duplicate of PEX7? PEX5 XML encoding detection in parse="text" ------------------------------------------- See http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0032 PEX14 What if encoding is not an EncName? ------------------------------------------- CONSENSUS to leave this as a dup of PEX3 and PEX7. PEX15 XPointers with percent escapes: what type of error? ----------------------------------------------------------- See http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0033 7. xml:id. The CR was published (2005 Feb 8) at http://www.w3.org/TR/2005/CR-xml-id-20050208/ The (public) xml:id LC issues is at: http://www.w3.org/XML/2004/xml-id/lc-status/status-report.html The LC DoC is at: http://www.w3.org/XML/2005/01/xml-id-lc-doc.html Our implementation report is at http://www.w3.org/XML/2005/01/xml-id-implementation.html We have a test suite cover page at http://www.w3.org/XML/Test/xml-id/ Norm sent some email at http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0023 and a sample of his implementation feedback at http://www.w3.org/XML/2005/01/xml-id/xmlidfilter-report ACTION to Norm: Add a link to the test suite from your implementation feedback report. ACTION to DV, Richard: Run your implementation on the test suite and produce some feedback report. Elliotte Rusty Harold is running the test suite and asking a number of questions we need to answer--see http://lists.w3.org/Archives/Public/public-xml-id/2005Apr/ Norm provided some answers to ERH's comments: http://lists.w3.org/Archives/Public/public-xml-id/2005Apr/0006 and 0007, 0008, 0009. We discussed changing wording about errors so that an xml-id processor doesn't need to report errors *to the application*. In Section 6 Errors, we currently say: A violation of the constraints in this specification results in an xml:id error. Such errors are not fatal, but must be reported by the xml:id processor to the application invoking it. ACTION to Richard: Suggest some rewording for this and pass it by ERH. 8. Associating stylesheets--awaiting TAG action. ACTION to Henry: Raise this issue at the TAG level (or just bring it back to us). 9. absolutivity of [base URI] Norm has asked a question about the absolutivity of [base URI]: http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0031 We discussed this at our f2f: http://www.w3.org/XML/2005/02/xml-f2f-20050303-minutes.htm#base-uri We have CONSENSUS that base URIs are always absolute. The last sentence of the first paragraph of section 5.1 of RFC 3986 says "If the base URI is obtained from a URI reference, then that reference must be converted to absolute form and stripped of any fragment component prior to its use as a base URI." Since the infoset and xml:base refer to 2396, it's not clear whether the fragment identifier is part of the infoset's [base URI] or not as life stands today. Richard: In 2396, base URIs can have fragment identifiers, but this doesn't matter because they aren't used when doing absolutization or determining if there is a same document ref. In 3986, base URIs don't have fragment ids, and again this doesn't matter for resolution, but it is essential that it be stripped off for the determine of whether something is a same document reference. In the infoset, we do expose the base URI as a property, and if we were to switch xml:base and XML itself from 2396 to 3986, the value of the base URI property would be different. Richard isn't sure we want to do that. ACTION to Richard: Draft a message for Roy et al. and send to the XML Core WG for discussion (later, to be sent to the uri group and the tag). paul [1] http://www.w3.org/XML/Group/Core [2] http://www.w3.org/XML/Group/Core#tasks [3] http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Apr/0013 [7] http://www.w3.org/XML/2004/02/proposed-xml10-3e-and-xml11-errata.html [8] http://www.w3.org/XML/xml-V10-3e-errata [9] http://www.w3.org/XML/xml-V11-1e-errata
Received on Monday, 11 April 2005 13:34:52 UTC