TAG Weekly Teleconference

19 Apr 2005


See also: IRC log


DanC, Dave_Orchard, Ed, Noah, Norm, Roy, Vincent
Henry, TimBL
Vincent Quint
Roy Fielding


Roll Call

<scribe> Scribe: Roy Fielding

<scribe> ScribeNick: Roy

Next meeting on 26 April

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

Accept minutes of 12 April

VQ: Any objections the minutes of 12 April telcon?

[no objections]

RESOLUTION: Accept minutes of 12 April

New issue? Squatting on link relationship names, x-tokens, registries, and URI-based extensibility


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?


Close issue xmlIDSemantics-32?

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

Review of XRI documents

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

<dorchard> http://www.pacificspirit.com/blog/2005/04/11/why_http_uris_are_better_than_urns_and_even_id_uris_for_identifiers

<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

Review of Binary XML documents

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

Reviewing WS-Addressing Core and SOAP Binding


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


Summary of Action Items

[NEW] ACTION: DanC to introduce new issue standardizedFieldValues-51 [recorded in http://www.w3.org/2005/04/19-tagmem-irc]
[NEW] 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.122 (CVS log)
$Date: 2005/04/26 18:41:59 $