- 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