- From: Grosso, Paul <pgrosso@ptc.com>
- Date: Wed, 16 Jun 2010 11:28:20 -0400
- To: <public-xml-core-wg@w3.org>
Attendees --------- Glenn Paul Henry Liam [4 organizations (5 with proxies) present out of 9] Regrets ------- Daniel (proxy to the chair) Jirka Simon Norm Absent organizations -------------------- Innovimax MarkLogics (with regrets) Opera (with regrets) Daniel Veillard (with regrets through the end of June, proxy to the chair) Jirka Kosek (with regrets) > > 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). Accepted. > > 2. Miscellaneous administrivia and document reviews. > > TPAC Nov 1-5 in Lyons, France > ----------------------------- > Paul indicated that XML Core tentatively plans to have a f2f > at TPAC, and we are currently scheduled for Monday/Tuesday > 1-2 November 2010. > > Likely: Henry, Mohamed, Liam, Daniel > Unlikely: Glenn, Paul, Simon, Norm > > Registration is now open; see http://www.w3.org/2010/11/TPAC/ > > TAG concern wrt 3023bis, +xml media types and fragids > ----------------------------------------------------- > Henry sent email about this at > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Jun/0006 > We will discuss this at our next telcon. 3023 does not talk about fragment identifiers (thought it should have). 3023bis does talk about fragment identifiers for xml media types, so this is the first time the +xml syntax for fragids is really discussed. 3023bis says that the +xml implies that the resource is suitable for processing by generic xml processors. And it says that such xml processors should handle fragment ids. Specifically, handling the fragment identifiers in an rdf+xml document is not something that a generic xml processor could do. The TAG was leaning toward removing the statement from 3023bis that says that fragid syntax and semantics is something that any generic xml processor can handle in a +xml resource. The TAG f2f notes with more details of the discussion should be available soon. At present, there is no action item here for this WG. > > 3. XML 1.0--see http://www.w3.org/XML/Group/Core#xml-errata > > > 4. XML Test Suite. > > See also http://www.w3.org/XML/Group/Core#xml-test-suite > > ACTION to Henry: Construct a test case for the XML test suite > issues raised by Frans Englich: > http://lists.w3.org/Archives/Public/public-xml-testsuite/2007Mar/ > > > 5. Namespaces in XML 1.0/1.1--see > http://www.w3.org/XML/Group/Core#ns1.0 > and http://www.w3.org/XML/Group/Core#ns1.1. > > > 6. LEIRIs--see http://www.w3.org/XML/Group/Core#leiri > > See > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Mar/0045 > from Dan Connolly which references > http://lists.w3.org/Archives/Public/www-tag/2010Mar/0037 > > At (among other places) > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010May/0001 > Larry Masinter explains the plan, to wit: > > http://tools.ietf.org/html/draft-ietf-iri-3987bis-00#section-1.3 > contains a definition in section 1.3 on "LEIRI proessing" which > should in fact be a definition of LEIRI: > > LEIRI: This term was used in various XML specifications to > refer to strings that, although not valid IRIs, were > acceptable input to the processing rules in Section 7.1. > > where Section 7.1 of the same document is intended to contain an > algorithm that will convert an LEIRI to an IRI. > > If that's adequate for XML Core to change its reference for LEIRI, > fine, and if you need more, please say so. > > A direct reference to Section 7.1 is > http://tools.ietf.org/html/draft-ietf-iri-3987bis-00#section-7.1 > > ACTION to Henry, Mohamed: Review the definition and discussion > of LEIRIs in http://tools.ietf.org/html/draft-ietf-iri-3987bis-00 > and let the WG know if this would allow us to replace our LEIRI > Note with a reference to this spec. > ACTION to Henry, Mohamed continued. > > 7. xml:id--see http://www.w3.org/XML/Group/Core#xml-id > > > 8. XML Base 2nd Ed--see http://www.w3.org/XML/Group/Core#xml-base > > > 9. XLink 1.1. > > See also http://www.w3.org/XML/Group/Core#xlink1.1 > > The XLink 1.1 Rec was published at > http://www.w3.org/TR/2010/REC-xlink11-20100506/ > > > 10. XInclude 3rd Ed--see http://www.w3.org/XML/Group/Core#xinclude > > > 11. Associating Stylesheets. > > See also http://www.w3.org/XML/Group/Core#assoc-ss > > Our latest public draft is at > http://www.w3.org/XML/2010/04/xml-stylesheet/ > > The transition request for AssocSS is at > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Apr/0034 > > We had an unsuccessful transition call last week. See > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Apr/0057 > > The editors drafted new wording for Section 2 Conformance; see > http://www.w3.org/XML/2010/05/xml-stylesheet/ > http://www.w3.org/XML/2010/05/xml-stylesheet/diff.html > > Paul sent email to Daniel Glazman and TimBL requesting comment at > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010May/0012 > and there has been no response. > > ACTION to Liam (as staff contact): Request that this latest draft at > http://www.w3.org/XML/2010/05/xml-stylesheet/ > be accepted as the PER per the transition request at > http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Apr/0034 > and that the PER review be published with appropriately adjusted > dates (which the editors and staff contacts should determine). > Liam has requested it goes to PER, but no response yet. ACTION to Liam: Follow up and push AssocSS to PER. > > 12. xml-model > > See also http://www.w3.org/XML/Group/Core#assoc-schemas > > This has been published as a WG Note at > http://www.w3.org/TR/2010/NOTE-xml-model-20100415/ > Jirka tells us that xml-model is now undergoing first ballot in SC34: http://www.itscj.ipsj.or.jp/sc34/open/1437.pdf > > 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/2010May/0002 > >
Received on Wednesday, 16 June 2010 15:28:55 UTC