- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Wed, 30 Mar 2005 11:40:28 -0500
- To: <public-xml-core-wg@w3.org>
Attendees --------- Paul Dmitry Norm Henry Daniel xx:18 François [6 organizations (6 with proxies) present out of 11] Regrets ------- Richard Glenn Absent organizations -------------------- IBM (with regrets) NIST University of Edinburgh (with regrets) Lew Shannon John Cowan > 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). Accepted. > 2. Miscellaneous administrivia and document reviews. > > The new XML Core WG charter should be in the process > of getting approved. We can expect a new call for > participation soon by the end of this week. > > The WG needs to review 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 is reviewing them already for the TAG. > > Dmitry, who is on the XBC WG, is also familiar with > the documents. > > ACTION to Dmitry: Send email before the telcon to > the XML Core WG outlining any issues in these documents > that may be of interest to the XML Core WG. Not all the documents have quite been released. ACTION to Dmitry continued--due by end of this week. > He recommends waiting until this Thursday to review > the measurement documents which will be changing > (the other two are ready for review). There will > be a fourth document, Characterization, that will > be published on or soon after this Thursday. > > ACTION to Lew: Review the documents and report to > the WG by the end of March. ACTION to Lew continued--due by end of this week. > Richard has been volunteered to review the > XPath 2.0/XQuery 1.0 Data Model document, to be published > as a LC WD in late March or early April (though there are > no plans to make any changes to it at this time, so the > review can start at any time). > > ACTION to Richard: Review the XPath 2.0/XQuery 1.0 Data > Model document: > http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/ > > Norm says the two key areas for XML Core to review are > Constructing a datamodel from an infoset and constructing > an infoset from the datamodel. > > Richard remembers there being something strange about > the PSVI, and he wants to check on that too. > > We should review the Compound Document Format (CDF) > Use Cases and Requirements document: > http://www.w3.org/2004/CDF/Group/specs/CDR/usecases/1.0/cdr-use-cases-reqs.xml > which talks about "combining separate component technologies > (e.g. XML-based languages, elements and attributes from > separate namespaces)...[including]... compounding by > reference and by inclusion." > > JohnC did a pass and saw nothing for XML Core WG. > > Paul still hopes to look at it. ACTION to Paul: Review the CDF document by end of this week. > > 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 > > > 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). ACTION to Richard continued. > 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 > > > PEX6 parse="text" and Byte-Order Mark > ------------------------------------- > What are the *{LE,BE} encodings? The answer is: UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE. > > PEX14 What if encoding is not an EncName? > ------------------------------------------- > While Paul thought this was a duplicate of PEX7, > Francois pointed out we could distinguish between > the PEX7 case and the case where the encoding > attribute value isn't even lexically valid per > XML 1.0 production [81]: > > [81] EncName ::= [A-Za-z] ([A-Za-z0-9._] | '-')* > /* Encoding name contains only Latin characters */ Francois suggests making it a fatal xinclude error if the XInclude processor actually goes to try to use an encoding value and that value doesn't conform to the syntax of EncName. What do others think? > > PEX15 XPointers with percent escapes: what type of error? > ----------------------------------------------------------- > See > http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Mar/0033 Henry raised the issue of the problems of xml:base, XML Schema, and XInclude; that is, that use of XInclude might require introduction of xml:base in a document whose schema doesn't allow xml:base. Given that all are Recommendations, no one could think of a good resolution here (short of saying that the schemas in question should be modified to allow xml:base). > > 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. > > ACTION to Norm: Ask ERH to run his implementation on > the test suite and produce some feedback report. Norm sent email to 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). ACTION to Richard continued. > > [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/2005Mar/0027 > [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 Wednesday, 30 March 2005 18:15:25 UTC