See also: IRC log
<scribe> Scribe: Roy Fielding
<scribe> ScribeNick: Roy
DC: we haven't published anything in
a while
... a working draft sort of thing
NM: I volunteer to scribe next week
<dorchard> possible regrets, may be on a plane
DC: regrets for next week
VQ: Any objections the minutes of 12 April telcon?
[no objections]
RESOLUTION: Accept minutes of 12 April
http://lists.w3.org/Archives/Public/www-tag/2005Apr/0033.html
DC: it would be great if they used a
URI, but they don't
... unclear if this is a new issue or an old one
VQ: Can it be addressed in the
context of one of the existing issues [scribe missed which
ones]
... preferencce for issue 41
NM: 41 carries too much baggage already, perhaps 9 (no)
NW: perhaps if it is hard to find the issue, it deserves a new one
<DanC> "The decision to identify XML namespaces with URIs was an architectural mistake that has caused much suffering for XML users and needless complexity for XML tools. "
<Zakim> DanC, you wanted to note http://www.xml.com/pub/a/2005/04/13/namespace-uris.html
DC: it seems we have failed to convince at least one person
VQ: inclined to proceed with a new issue
RF: okay by me
<DanC> issue makingNewTerms ...
<DanC> issue linkRelationshipNames
DC: trying to think up a name
NM: preamble about media types would indicate relationship to issue 9, but I guess that was just a lead in -- we should be clearer that this is about the short name issue
VQ: just link relationships, or broader?
NW: would prefer broader issue of short names
<DanC> standarizedAttributeValues
<DanC> hmm
RF: standardized attribute values in
content
... I meant attribute values in general, not just in XML syntax
<DanC> standardizedFieldValues
RF: works for me
<Norm> Works for me
[no objections]
RESOLUTION: create new issue standardizedFieldValues-51
DC: does anyone else think they should use URIs?
<Norm> Interestingly Atom "gets this right" AFAICS. "foo" => http://www.iana.org/assignments/relation/foo
RF: I proposed the IANA-based registry used by Atom relationships
DC: what does it mean to add a relation name? Can they be a URI? How do you get an IANA name?
<Norm> I suppose someone should define the mechanism for adding to the registry, writing an RFC maybe?
DC: suppose I just introduce a short name
NM: is it formally defined as a relative URI?
RF: it is formally defined as a suffix of the IANA base URI if the value is given as a short name instead of a URI
<scribe> ACTION: DanC to introduce new issue standardizedFieldValues-51 [recorded in http://www.w3.org/2005/04/19-tagmem-irc]
<DanC> (hmm... "standardized" is perhaps narrower than I'd like, but no matter)
VQ: shall we wait and see the feedback from the introduction before continuing?
[agree]
NW: CR was published, in the process
of implementation reports
... inclined to continue this until PR
DC: looking at how this impacts other
(existing) specs and what tests are needed
... trying to address concern about W3C having many individual
specs that don't always work well together
... for example, Chris looked at this and provided examples where
various specs (like CSS) should be updated/revised to reflect the
change
NW: I don't think it would be appropriate for CSS to say anything about xml:id because the current [algorithm?] will pick up the new id automatically because it starts with the infoset
NM: I think both views of this are
right, there is a case to be said that the infoset way is
architecturally better
... OTOH, Dan is right as well and we need to provide [details
missing]
NW: agrees in general
<Norm> ACTION: Norm to point out to the Core WG that it would be good to get the CSS working group to buy into xml:id [recorded in http://www.w3.org/2005/04/19-tagmem-irc]
<DanC> (the corresponding concern applies to xpath etc.)
VQ: I guess we can conclude that we should not close the issue? Do we agree?
DC: yes, but would like to hear from other TAG members
NW: Xpath 2 has support for xml:id construction, Xpath 1 can support it providing that it starts with an infoset
DC: surprised, so that means something that used to conform will no longer conform?
NW: both still conform
[technical discussion of XML processing continues by NW, NM, and DC, specifically regarding how many XML technologies are now specified by way of the infoset rather than a specific document format, and how that impacts conformance testing]
RF: This infoset issue may lead to problems in regard to the other discussion about binary XML and the perceived notion that XML == text.
VQ: let's get back to the specific issue at hand
<DanC> http://www.w3.org/TR/2005/CR-xml-id-20050208/#impact
DC: I would like for this section C to have a test case prior to going into effect
NW: would like Dan to send mail to
public-xml to that effect
... I don't know how to construct a test for CSS, but the
introduction of xml:id does not change historical documents and its
presence will be ignored by parsers ignorant of xml:id. The CSS
spec doesn't need to say anything about that.
VQ: I suggest revisiting this after Norm completes action ... are there any other specs beyond CSS that are impacted?
DC: six specs are listed
VQ: let's move on
VQ: Henry is not here, but can Ed provide his feedback?
Ed: I sent HT some feedback this morning but haven't heard back yet (my delay)
VQ: we need to reply to the WG by the
end of this month
... and work on a longer document
Ed: HT is working on the longer document ... after feedback, will have a better idea how to proceed toward sending comments to WG
VQ: should we prepare something specific for the XRI team?
Ed: yes, they deserve a direct feedback as opposed to a general reference
RF: agree on direct response (as well as later general document)
VQ: running out of time, will we have time to make a TAG decision?
DC: we already have general feedback in the form of the webarch doc
DO: we need to take a look at the
examples given and explain how we can solve those problems using
URI, HTTP, etc.
... on my blog, I got comments about change of ownership of a
domain and broke it down into examples
... that show how the points can be responded to
<DanC> http://www.pacificspirit.com/blog/2005/04/19/dns_changes_dont_break_http_uris
<Zakim> DanC, you wanted to propose: 1. XRI follows the pattern of an administrative hierarchy of delegation ending with a path, 2. http/dns handle that case, and is ubiquitously deployed
DC: I wonder what parts of that argument would fail to convince?
DO: what's not established is
"http/dns handle that case"
... they wrote a document that shows (in their mind) why 2) is not
the case. What we need to do is come up with examples that show an
alternative interpretation/solution to the examples they provided
in the documents.
DC: did their writing convince you?
DO: it did give me pause to wonder about the two scenarios already mentioned
Ed: most cases of domain change can be handled by redirects
NM: is it obvious to people on this call that redirect is something that we can point to for longevity of URIs?
DC: yes, one of the many reasons why
HTTP is better for this type of thing
... I am willing to try to make that case (am writing a related
article)
VQ: can you do that such that we have something to approve next week?
<DanC> (my target is now end of day weds)
<DanC> ACTION DanC to elaborate on "http/dns handle the case of an administrative hierarchy followed by a path"
Ed: we should be able to have enough material to reply next week
Ed: I have this afternoon set aside for this
<DanC> sounds like ed's action continues
Ed: should it be in finding form or just an email?
NM: perhaps less formality is desired for a response to a WG
Ed: agree
http://www.w3.org/2005/03/29-tagmem-minutes.html#item03
DC: endPointRefs-47
<DanC> http://www.w3.org/2001/tag/issues.html?type=1#endPointRefs-47
DC: suppose we just withdrew this from our list?
NM: what about the general concern
that they are using something other than URIs for general
identity?
... what WSA did was remove the distinction that indicated a
parameter was being used for identity, but they didn't remove the
mechanism itself. Some people still use that feature for the
purpose of identification.
DO: similar to cookies in that WSA
does not prevent the use of those fields for the sake of passing
identifying data
... but not all such fields are used in that way
<DanC> (hmm... [[ WS-Addressing is conformant to the SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework] processing model ...]] )
NM: I think these questions are still present, and though not directly tied to this issue it may be our last chance to deal with non-URI addressing
VQ: we are out of time
ADJOURN