- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Wed, 26 Jan 2005 11:59:26 -0500
- To: <public-xml-core-wg@w3.org>
Attendees --------- Paul Glenn Sandra Anjana xx:11 Norm Leonid Richard Henry Phillipe John xx:11 François Lew DV xx:54 [11 organizations (11 with proxies) present out of 11] Regrets ------- Dmitry Absent organizations -------------------- Daniel Veillard > 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. > > The next W3C Technical Plenary Week will be 28 February 2005 > through 4 March 2005: > http://www.w3.org/2002/09/TPOverview.html > http://www.w3.org/2004/12/allgroupoverview.html > > The XML Core WG f2f meeting days will be Thursday and Friday, > March 3rd and 4th. Wednesday is the Plenary day to which all > XML Core WG members are invited. > > Register for the meeting at: > http://www.w3.org/2002/09/wbs/35125/TP2005/ > > Register at the hotel: > http://www.w3.org/2004/12/allgroupoverview.html#Venue. > The negotiated room rate at the meeting hotel, Hyatt Harborside, > http://harborside.hyatt.com/property/index.jhtml is $139 (plus > 12.45% tax); this discount rate expires 5 February 2005. > > We have a tentative meeting time with the TAG on Thursday > right after lunch during the Tech Plen week in case we have > something to discuss with them by then. > > There should be a Technical Plenary week discussion about > "Extensibility and Versioning of XML Languages"? See > http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Jan/0013 > Norm will probably participate. This is no longer scheduled as a separate discussion due to lack of response. However, it is still expected to be a topic during the Wednesday TP meeting itself. > > 2.5 All XML Activity WGs have been asked to review > QA Framework: Specification Guidelines > http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/ > whose Last Call Ends 28 January 2005. > > Paul sent in our comments: > http://lists.w3.org/Archives/Public/www-qa/2005Jan/0025 > > > 3. XLink update. > > Our WG Note "Extending XLink 1.0" is supposedly still on > track for publication this Thursday--the request is at > http://lists.w3.org/Archives/Member/chairs/2005JanMar/0017 TBL has approved publication but asked the following about our point 2: The point about reserving the namespace is interesting. The namespace is in w3.org space, and so is owned by W3C. This fact follows from the architecture. So w3c has change control of the namespace. This is normal. What was the group woried about? Other standards bodies or manufacturers "squatting" on the space by inventing new things? Our point is to ensure no one outside the W3C make inappropriate use of this namespace, especially individual authors (but maybe also some implementators). We believe that the current XLink 1.0 wording--that "no meaning is defined by XLink" for other attributes in the xml namespace--may mislead people into thinking they could define such uses. We wish to ensure this misconception doesn't occur. > > 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]. > > > 5. Namespaces in XML. > > Ongoing ACTION to Richard: Produce a draft for NS1.0 2nd Ed. > > Paul checked with W3C folks about whether we can > fold editorial errata from 1.1 back into 1.0 2nd Ed > and our plan is acceptable: > http://lists.w3.org/Archives/Public/public-xml-core-wg/2004Nov/0041 > > Richard pointed out a namespace comment at > http://lists.w3.org/Archives/Public/xml-names-editor/2004Dec/0000 > which requests something which is almost a different kind of schema. > > ACTION to Richard: Send email outlining the issue and your suggested > resolution. ACTION to Richard continued. > > 6. Xinclude Rec was published 2004 December 30 at: > http://www.w3.org/TR/2004/REC-xinclude-20041220/ > > It has been brought to my attention that we apparently failed > to look at the public XInclude comments list for comments > received during the PR review which is basically the October > archives for this list: > http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2004Oct/ > We will treat these are errata. > > DV volunteers to be editor of the XInclude errata process. > > ACTION to DV: Create a PE document for XInclude. ACTION to DV continued. > > 7. xml:id. > > Our Last Call of xml:id is published at > http://www.w3.org/TR/2004/WD-xml-id-20041109/ > > The latest WG draft (dated 2005 January 18) is at > http://www.w3.org/XML/Group/2004/xmlcore/xmlid/xml-id.html > > The (public) xml:id LC issues is at: > http://www.w3.org/XML/2004/xml-id/lc-status/status-report.html Norm posted an LC DoC 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 > > Paul sent out a draft CR request at > http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Jan/0046 No comments. Paul will update with the test suite URL. CONSENSUS of the WG to request CR for xml:id. > It looks like the CR call will be this Friday morning. Though maybe not given Ian Hickson's objections, since we may now need to have TBL on the call. > We will need a test suite. > > Norm has created a test suite. > > ACTION to Norm: Put the test suite into public space. Done. > ACTION to Sandra: Create an xml:id test suite front page. Done, and Paul has put it up at http://www.w3.org/XML/Test/xml-id/ > ERH raised an issue with xml:id and canonicalization: > http://lists.w3.org/Archives/Public/public-xml-id/2005Jan/0037 > Norm's forward to the XML Core list: > http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Jan/0049 We agree that the problem is a problem in the C14N spec. The C14N spec is not currently being maintained by any WG, so Henry suggests we pick it up to correct this "erratum". ACTION to Paul: Email the XML CG about this problem. It was pointed out that no one can be using xml:id now, so all we are invalidating are implementations, not documents. Richard points out that xml:base already do not work properly if it is assumed to inherit as specified in the C14N spec. For the purposes of xml:id, all we can do is include a non-normative Note about this problem. ACTION to Norm: Add such a non-normative note. > Ian Hickson objected to two of our resolutions--we should discuss. ID assignment and the empty string ---------------------------------- http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Jan/0051 http://lists.w3.org/Archives/Public/public-xml-id/2005Jan/0024 Richard just replied at http://lists.w3.org/Archives/Public/public-xml-id/2005Jan/0054 We don't want to make the empty string magic. We want xml:id="" to behave analogously to how id="" (where id is declared ID) behaves. Note that, per the Infoset spec, the [attribute type] property in the infoset is set to the declared type regardless of the validity of the value. This is already true for attributes declared of type id, so our proposed behavior for xml:id matches that already the case for declared ids. normalization ------------- http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Jan/0052 http://lists.w3.org/Archives/Public/public-xml-id/2005Jan/0022 We want xml:id values to be normalized in the infoset. Ian says browsers don't now do this; he doesn't like the fact that we are changing the infoset values for xml:id from what they would be in an infoset created by an xml:id unaware processor. But we are quite sure we do want to do this for xml:id. Given that we are changing the type of xml:id from CDATA to ID, it doesn't seem additionally problematic to normalize its value too. It won't break existing documents, since there can be no existing documents that use xml:id. Our proposed behavior is equivalent to putting something in your internal subset declaring xml:id to be an id. > ACTION to Norm: Produce a CR-ready draft of xml:id. ACTION to Norm: Adding non-normative rationale for xml:id. To be done before COB today. 8. What to do with xml:* elements in a schema when there isn't a declaration for them. Henry said MS had a question here that arises as a consequence of xml:base fixup in XInclude. The Schema WG was asked how to handle the case that XInclude defines xml:base fixup which ends up adding xml:base attributes to elements whose schema definition doesn't allow the xml:base attribute. Should Schemas be changed to allow xml:* attributes by default? Richard thought not, but we can reconsider making the presence of xml:base in XIncluded infosets optional at user option. John pointed out folks are looking at xml:lang in a similar fashion. XInclude has xml:lang fixup, so there is a similar situation here too. Henry was satisfied with the discussion for now, but we should leave this as an open issue for us. > > 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/2005Jan/0044 > [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, 26 January 2005 16:59:36 UTC