Minutes for XML Core WG telcon of 2005 February 23

Attendees
---------
Paul 
Glenn  xx:11
Arnaud  
Dmitry
Norm 
Leonid
Richard
Henry 
Daniel
Lew

[8 organizations (8 with proxies) present out of 11]

Regrets
------- 
Sandra

Absent organizations
--------------------
NIST (with regrets)
John Cowan
François Yergeau


> 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 NEXT WEEK:
>      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.

The current draft agenda for our f2f is at
http://www.w3.org/XML/Group/2005/02/xml-f2f-20050303-agenda.htm

If you are not attending in person, we do expect dial 
in via Zakim (and IRC) to be available:

XML_XMLCore(TP)
XML Core Working Group
Thursday, 3 Mar - Friday, 4 Mar
8:00am-5:00pm/13:00-22:00 UTC
Zakim Bridge +1.617.761.6200, conference 9652 ("XMLC")
5 participants

> We will NOT be having our usual Wednesday telcon next 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
> 
> 
> 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.

We may discuss this next week.

> 
> 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.

DV generated a first pass at
http://www.w3.org/XML/2005/01/proposed-xinclude-errata

ACTION to DV:  Make corrections, additions as outlined
in Paul's email at:
http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0064


> 
> 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/
> 
> The issue of xml:id vrs C14N and the definition of
> namespaces is ongoing, originally in the xml:id 
> comments list and now on the www-tag list.  It seems
> likely that the TAG will pick up some issue out of this.
> 
> Norm has asked for this topic to be on the TAG's telcon
> this week (Tuesday afternoon).

The TAG agreed to pick it up as an issue.  This will be
a topic for our f2f with the TAG.

> Norm will need to do some work on the test suite.

ACTION continued.

> 
> 8.  Associating stylesheets
>     We have had several requests to issue some clarifications
>     on use of fragment identifiers in URIs to referenced
>     stylesheets:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0022
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0030
> 
> We discussed that the resource should be retrieved per
> the URI (not counting the frag id), then any frag id would
> be interpreted according to the type of the retrieved resource
> to produce what the SS PI refers to.  Then, the application
> using the SS PI may look at the type pseudo-attribute to
> help it how to interpret the returned (sub-)resource.
> 
> Norm: frag id are interpreted by the mime type sent back
> by the server (so the type pseudo-att is ignored until
> whatever (sub-)resource is returned and determined).
> 
> The SS spec could say what to do for various type's
> (including what might be acceptable/erroneous).
> 
> [The replacement to RFC 2396 is 3986.]
> 
> We had general CONSENSUS to do something to clarify
> the SS spec.
> 
> John thinks we can do this by issuing a clarificatory 
> erratum.  Paul tends to agree, though done in coordination
> with the HTML/CSS WGs.  Henry is less sure, and wants to 
> know more about what the HTML CG thinks.  The problem is
> that the HTML spec "defines" the semantics of the type
> attribute, but we want the SS spec to do so.
> 
> John says we should deprecate the charset pseudo-attr
> of the SS PI while we're at it.
> 
> Paul raised this issue with the XML CG and Chris Lilley
> is acting as the XML Activity liaison with the Hypertext
> CG group.  There has already been some discussion:
> http://lists.w3.org/Archives/Member/w3c-xml-cg/2005Feb/0036 ff

ACTION to Paul:  Look into a joint f2f with some HTML CG 
folks in Boston.

Henry reports there is some action in the HTML activity on
this topic at this time.  They point out that the type might
be useful in picking which resource to retrieve when the
application knows what kind of stylesheet it prefers.  Norm
says that's just application behavior, and we don't have to
worry about that.

Norm says, regardless, the application decides in some fashion
what resource to retrieve, when it retrieves it, it looks at
its mime type and that mime type to process the frag id.  The
app then uses the type attribute to process the subresource
it now has.

One interesting case is when the URI points
to an XML document and the frag id is an xpointer
to a <style> element and the SS PI's type attribute
is text/css.  Henry says that Bert says that, if we
get this far (and it looks like we may well), that
the HTML and/or CSS folks will issue something saying
how to handle this.

> 
> 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
> 
> Norm thinks we should make an erratum to the infoset spec
> that says that the [base URI] is always absolute (unless
> there is no absolute [base URI] at all for the resource).
> 
> XML Base bullet point 1 in 4.2 isn't clear enough.
> The second bullet of 4.3 does help.
> 
> John interprets 5.1 of RFC 2396 to say that base-URIs
> are absolute, but Paul doesn't agree that this is clear.
> 
> We have CONSENSUS that the [base URI] is always absolute.
> 
> We have CONSENSUS to make a clarificatory erratum to the 
> Infoset that indicates that [base URI] should always be
> absolute (unless it's impossible).  
> 
> Henry thought we needed to allow frag ids in [base URI].
> Henry sent email on this at:
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0052

JohnC and Norm agree with Henry that we shouldn't say anything
special about frag ids on [base URI].

Richard asks if the empty URI--which refers to the [base URI]
now in 3986--refers to the whole document or just the fragment.
Looking at 3986, he decides the empty URI refers to the whole
document.

Henry and Norm think that a careful reading of Infoset, xml:base,
and RFC 2396 already imply that [base URI] is absolute, but we
agree that being more explicit can't hurt.

Norm thinks we should add a clarificatory note to the
Infoset pointing out that the consequences of xml:base
processing implies the [base URI] will always be absolute.

We had CONSENSUS to do so.

ACTION to Richard:  Process the above as an erratum to the
Infoset spec.

> 
> 10. XML 1.1 and C1 control characters
>     Norm has raised a question about the need to escape C1 control
>     characters in XML 1.1 (which is backward incompatible 
> with XML 1.0):
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0033 
> 
> There was some email discussion at
> http://lists.w3.org/Archives/Public/public-xml-core-wg/2005Feb/0054 ff

Norm remains irked that we have a backward compatibility
with XML 1.1, but this horse left the barn a long time ago,
so we are going to drop this issue.

> 
> [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/2005Feb/0051
> [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, 23 February 2005 17:11:00 UTC