TAG Telcon

<raman> any one have thoughts on what the filename for my hash in url finding should be?

<DanC_lap> hash-in-url.html

<raman> It's currently hash-in-url.html

<Stuart> so... raman that's your work on webApplicationState-60?

<raman> Stewart -- could you give me a pointer to the TAGissue that this finding addresses so I make the appropriate noises in the right places in the abstract?

<Stuart> http://www.w3.org/2001/tag/group/track/issues/60

SW: DO will join late
... Agenda slightly changed since yesterday's version

RESOLUTION: Minutes of previous meeting approved: http://www.w3.org/2001/tag/2008/02/07-minutes

SW: Meeting on 21 Feb, DanC to scribe
... Regrets from TBL for 21 Feb

Issue abbreviatedURI-56 (ISSUE-56)

See http://www.w3.org/2001/tag/group/track/issues/56

SW: NW, HST and SW have reviewed

<noah> Norm's comments seemed OK to me. I particularly liked Henry's comment on QNames in attribute values.

NW: To summarize: Just Say No

DC: It's in their charter

TBL: It addresses a real need

DC: Is it in their charter?

JR: Yes it is

DC: So, NW, still opposed?

NW: Yes -- I think the proposed solution is too confusable with QNames and URIs themselves
... The "Not appropriate for attr vals" argument is just wrong

TBL: QNames weren't intented for content at all, see WebArch for dangers

NW: They didn't point to that at all, if that's what they meant, the argument works equally well against CURIEs

<Stuart> <link property="prefix" content="myPrefix" href="http://www.example.com/myPrefix/" >

NW: They use both the xmlns...= and other mechanisms to establish prefix binding

DC: If you know to look for a CURIE, you know to look for this 'prefix' property

NW: But there are no limits on the number of ways different specs could specify prefix binding mechanism
... Whereas at least for xmlns, XSLT knows how to find the binding

<Zakim> noah, you wanted to ask how much of the rationale for CURIE is the claim that QNames don't work in attributes.

NM: Saying "Can't use QNames in attr vals" is too simple
... So how much of the rest of their argument goes away
... Does the whole thing go away?

HST: No

NW: No, the req't is to use isbn:1234 to identify something, and 1234 is not an (XML) Name, so isbn:1234 isn't a QName

SW: DC asks what we're doing with this agenda item
... we have to decide to endorse some or all of the comments

HT: Or add some new ones
... I wrote mine as input to a TAG comment

SW: I wrote mine directly to the WG, TAG could endorse

NW: ditto

<Zakim> timbl, you wanted to mention improving XML in general (bare params are qnames, qnames ana URIs interchangable in some way, etc , but also mention N3

<noah> How about XML Namespaces 1.1 5th Edition?

<DanC_lap> (yeah... where is XML 1.1 in the process? why not fix this isbn:1234 problem while we're fixing the unicode issues?)

<Stuart> FYI... my input landed on www-html-editor@w3.org http://lists.w3.org/Archives/Public/www-html-editor/2008JanMar/0007.html

TBL: Clean thing to do is fix this for everyone, because you can't use URIs and QNames interchangeably, either in attr values, or as elt names

<noah> (I suppose I should admit that I personally have at best mixed feelings about the XML 1.0 5th edition proposal, so the proposal above was made somewhat in jest.)

TBL: Pbly ridiculous to think about the TAG proposing an XML 2.0
... I mostly use N3, where prefixed names and URIs are interchangeable

<jar> but n3 (unlike sparql) doesn't support isbn:1234

TBL: but it's not embeddable, because it uses angle brackets

<DanC_lap> n3 will probably pick up isbn:1234 from sparql

HT:Two distinct things...

<timbl> Yes.

<timbl> :123 being different from 1234

<timbl> (and from 123!)

ht: ... first: if framed as a new xsd datatype with lexical and values space... and mappings... and a constraint to being used only in new languages...

<noah> Henry, we do have the problem that XML Schema doesn't quite clearly allow for new primtive types.

<noah> Certainly using it in a Schema Structures document would be problematic, unless you would propose it as a subtype of string?

ht: ...then, fine... go ahead, but stay away from href.

ht: ...the Schema WG is in serious discussion about allowing new xsd datatypes.

<noah> I'm not happy prejudging the pros and cons of whether XML Schema should allow for user defined primitives. The upsides are clear, but it raises very serious interoperability concerns for Schemas in particular.

ht: ...second: I observe that if we did all of that they would not get what they wanted because it would not make ....#12345 a URI.

<DanC_lap> (what's not a valid URI?)

<ht> Anything of the form ...#1234

<DanC_lap> let's fix that bug that 1234 isn't a name.

<noah> Norm: What Henry means is, if those ...s resolve to somethign of media type application/xml, then 1234 isn't a good fragid per the pertinent specs.

<DanC_lap> 1234 is a perfectly good name in many business contexts, ISBN being the one already introduced in this conversation.

ht: I'm unaware of a media type where a number is a valid fragid

<noah> Yes Dan, but the question is, which media types allow for them in fragids?

<jar> has curie:isbn:12345 been proposed?...

<Stuart> ht: refers to email to XML core.

<noah> Norm, when you come up on the queue, could you also clarify XHTML? I would have thought that would be more restrictive, for better or worse?

<Zakim> DanC, you wanted to ask about allowing isbn:1234 in XML 1.1 and to note that the QName datatypte doesn't fit XML Schema's definition of a datatype and to give an example: the value

DC: XML 1.0 5e is where in the process? We're asking them to change how names are parsed, can we do this too?

<timbl> I wonder what happens in E4X

<Zakim> Norm, you wanted to observe that I'm not sure Henry is right about the HTML 4.01 case. 12.2.1 does not say that @name on "a" has to be an NCName AFAICS

DC: QName is inconsistently defined in Schema -- abc:xyz can denote two distinct values at two points in a document, which is not consistent with the statement that there is a mapping from lexical to value space.

<DanC_lap> (the use of #123 is widely practice, all the way back to the 1st HTML document I ever saw; I got TimBL to change the WorldWideWeb app to use #z1 but the rest of the world doesn't bother.)

NW: In both HTML and XHTML you can use the NAME attribute on anchors, which doesn't say anything about being an NCname
... I don't think we can or should allow 1234 to be an element or attribute name

DC: Why not

NW: I don't know of any programming language which doesn't distinguish between identifiers and numbers

<raman> in json, I can have a key called 1234

TBL: XML is close to a programming language, and I don't want to have a number/name confusion

<DanC_lap> (even in the javascript case, some xml names have to be mangled in order to fit. so 1234 would have to get mangled in some cases. such is life.)

TVR: JSON today allows numeric keys, which ipso facto can't be mapped to XML

TBL: Same pblm in E4X

DC: Some XML names (minus signs) already fail to map to Javascript names

<jar> out how to be constructive

<DanC_lap> close action-80

<trackbot-ng> ACTION-80 Review http://www.w3.org/TR/2007/WD-curie-20071126/ closed

<DanC_lap> close action-81

<trackbot-ng> ACTION-81 Review http://www.w3.org/TR/2007/WD-curie-20071126/ closed

<Zakim> noah, you wanted to talk about XML 1.0 5th edition

<DanC_lap> close action-82

<trackbot-ng> ACTION-82 Review http://www.w3.org/TR/2007/WD-curie-20071126/ closed

SW: What about the three comments on the table: Deem relevant actions closed, endorse them to the WG, add anything further ?

NW: Further discussion of names/numbers/XML vNext out of order?

SW: Yes -- we'll discuss that another time

<Zakim> timbl, you wanted to whone about scripting languages and JSON etc

DO: Did DC say that XML 1.1 had become XML 1.0 5e -- true?

NM: Not quite

<Zakim> jar, you wanted to say (briefly) that the reviews are negative. there's a real problem & we should figure

DO: I would have concerns in our future discussion

JR: I'm concerned that the three reviews are largely negative, but the problem is real, and they're asking for help to stop it going in 5 different directions

<raman> Strongly concur with Jonathan.

<DanC_lap> (I think it's quite reasonable for curies to go 5 different ways in 5 contexts; abbreviations are a per-language, local design issue.)

<raman> TAG saying "no" will just get us ignored; may html5 be a lesson to all

DC: So what should they do?

JR: We need to at least recognise their requirements
... not asking that we give the solution

<DanC_lap> (I think the thing to do is to change the fact that 1234 is not a name in XML, or at least in namespaces)

HT: I would not object if they were clear that this is a new datatype for new uses

<DanC_lap> -1 use say that curie is an XML schema data type. it's not.

NW: I could go with that, but not with taking a position on defining a new primitive simple type
... Certainly premature to ask Schema WG to add CURIEs to the next edition
... What is your proposal HT?

HT: Three things resolved/changed: 1) xmlns binding only; 2) new contexts/new languages only; 3) Provide a simple type definition derived from xs:string

<noah> Ah, if you think derived from xs:string does it, then maybe, but I would have thought that like xs:QName it should not be derived from xs:string.

SW: In my review I didn't take an overall position, but I do think that for a spec. aimed at language developers/designers is an XSD datatype, so they should provide that, including both lexical and value
... The thing they keep saying is that QNames are a subset of CURIEs, but that's clearly false wrt the value
... they should clean that up
... Those are the two substantive parts of my review

<Zakim> timbl, you wanted to ask for a list of what softwre would have to be changed. Strt with N3 serializers.

DC: Can't have a datatype, because the value is not determined by the lexical form

<DanC_lap> (n3 is one of the "5 or six different ways" that CURIEs are going, as jar said, ht.)

TBL: What software would have to change? We would have to change N3 to accept the kind of things that CURIEs will construct

<raman> shouldn't needed changes to n3 be balanced against other implementations, and what their needs are?

<DanC_lap> yes, n3 changes should be balanced against all the other changes

<jar> ht, the implications of qnames go way beyond xml - that this is not clear is i think a deficiency of their introduction

NM: So you think this will expand the range of URIs to which these things map

TBL: I will have to change the syntax of N3 to no longer restrict to QNames

<timbl> People will start to use things of th for m htp://\/dfjhdfhjs/dsfjhfs/sdf//isbn#1234567

ht:They already do

<noah> Yes, but just as a clarification, you won't necessarily have to support the CURIE compact syntax or prefix bindings in particular.

HT: They are already writing such URIs, why will CURIEs make this worse?

<jar> ht, standardization! the same curies for everyone who does curies

<noah> You will have to make your own compact syntax in N3 capable of dealing with the expanded range of "URIs", I.e. with numerics.

SW: We have three reviews that could stand as they are

SW: Propose the TAG endorse all three comments

HST, TVR, others: No

SW: Propose the TAG say nothing

DC: No

TVR: I've heard the TAG express some doubts, but I don't think we've looked hard at their use cases, maybe we should get one of them to talk to us

<DanC_lap> +1 invite somebody

<DanC_lap> +1 to fix the restriction on XML

HT: -1, we don't need to hear from them in person, we understand their use cases

<Norm> I concur with Henry

HT: I will put together a consensus proposal but not until next week

<DanC_lap> +1 to HT taking the ball

<jar> +1 to ht to taking the ball - i'm happy to help but can't do it all

TVR: What would that proposal look like?

<jar> tag should not do design (in this case). should be socratic, i think

<DanC_lap> (where does 4 weeks come from?)

HST: Proposal would be of the form: fix these bugs, and we have no further objections -- might not be what we would have done, but that's not our job
... 4 weeks was my confusion, this is not a Last Call WD, we are not under explicit time pressure

<DanC_lap> +1 HT to synthesize something and get jar to look at it for next week

TBL: SHould include a discussion of what else will have to change
... Does it mean we have to accept identifiers which begin with digits?

<jar> curies are not specific to xhtml. i agree with ht that correct point of action is not obvious

<scribe> ACTION: HST, with help from JR, to try to formulate something which pulls our input together [recorded in http://www.w3.org/2008/02/14-tagmem-minutes.html#action01]

<trackbot-ng> Created ACTION-100 - HST, with help from JR, to try to formulate something which pulls our input together [on Henry S. Thompson - due 2008-02-21].

httpRedirections-57 (ISSUE-57)

See http://www.w3.org/2001/tag/group/track/issues/57

See http://www.w3.org/TR/2007/WD-cooluris-20071217/

SW: There was some uncertainty in our interactions with them
... We thing the diagram change is crucial to TAG approval
... NW is waiting for a final draft to do a further full pass
... We should go back to them and say we need a final draft

HST: Do you mean we should wait for last call

<DanC_lap> (there's nothing minor about the change to the diagram.)

<DanC_lap> +1 next draft

DC: Not if we think we will have comments

HST: What was the disconnect?

SW: We thought @@ meant ' We will do more ', but it actually meant ' What does the TAG think of this change '?
... and there's the diagram issue

DC: I think we didn't communicate the diagram to them clearly enough -- I think I got 'hunh?' feedback from them

SW: Can you, DC, clear that up?

DC: Yes, with help from TimBL -- would take 45 mins

<jar> diagramming tool: i like omnigraffle ...

<scribe> ACTION: Dan, Tim to produce Visio diagram to send to Leo [recorded in http://www.w3.org/2008/02/14-tagmem-minutes.html#action03]

<trackbot-ng> Created ACTION-101 - Dan, Tim to produce Visio diagram to send to Leo [on Dan Connolly - due 2008-02-21].

<dorchard> I was liking violet for the versioning files..

<DanC_lap> yes, I like violet. if timbl can stand it, we'll use that, maybe

SW: I need to set some expectations with SWEO, they are short on time

<DanC_lap> violet is nice in that I know how to get RDF/OWL from it

DanC, I improved (I think :-) your stylesheets for that purpose, will send to you

<Stuart> http://lists.w3.org/Archives/Public/public-sweo-ig/2008Feb/0021

<DanC_lap> (I struggle a bit with email interactions with SWEO; I keep finding their mail stuck in my klunky spam defenses.)

<Stuart> http://www.w3.org/TR/2007/WD-cooluris-20071217/#distinguishing

DC: Should Tuesday night group look at this?

TBL: [Maybe]

<jar> cswg is not a discussion really.... we had about 50 people at the last one

<Zakim> Norm, you wanted to say I don't want a last call, I'd just like the next draft. Hopeflly with revised diagrams and finished "TODOs"

NW: I do not require a Last Call draft, will review the next draft they complete

SW: I will go back to Leo

<Stuart> http://www.w3.org/TR/2007/WD-cooluris-20071217/#distinguishing

<DanC_lap> "This is a First Public Working Draft of an intended W3C Interest Group Note giving a tutorial explaining decisions of the TAG for newcomers to Semantic Web technologies"

SW: I would like to see this end up as a NOTE, rather than be dropped

<DanC_lap> "Febr 2008 - The SWEO Interest group ends." http://www.w3.org/2006/07/sweoig-charter.html#schedule

SW:The rest of HTTP Redirections will be on next week's agenda.

F2F

SW:Draft of F2f Agenda is posted. Looks pretty full. Comments solicited.

<DanC_lap> (places that need work will are marked how? I looked for @@'s and didn't find them.)

<noah> ADJOURNED

<timbl> Exeunt, chased by a bear