November 2004 Meeting in Cambridge, MA, USA

Norman Walsh and Paul Cotton, meeting chairs
Dan Connolly, Noah Mendelsohn, Chris Lilley, Roy Fielding, scribes
$Revision: 1.19 $ of $Date: 2004/12/09 18:44:46 $
contents: Participants * Agenda/Summary * Venue * Minutes
nearby: issues list * TAG Issues grouped by theme * www-tag archive * irc 29Nov * irc 30Nov


tag in CSAIL

  1. Tim Berners-Lee (in part) (TBL)
  2. Dan Connolly (DC)
  3. Paul Cotton (PC)
  4. Roy Fielding (RF)
  5. Chris Lilley (CL)
  6. Noah Mendelsohn (NM)
  7. Dave Orchard (DO) (observer; in part; not pictured)
  8. Norm Walsh (NDW)
  9. Stuart Williams (SW) (by videoconference, in part)

Janet Daly and Benjamin stopped by to say hi.

Agenda, summary of Actions and Decisions

  1. Convene, take roll, reivew records and agenda
  2. Meeting Planning ACTION CL
  3. Future Directions for WebArch, TAG
  4. AC Meeting Preparation ACTION CL
  5. Tech Plen planning
  6. PR comment: Opera on 4.3 (Separation of Content, Presentation, and Interaction)
  7. PR Comment: Nokia on "namespace document" ACTION NDW
  8. PR comment: Character encoding from Eric Bruchez ACTION CL
  9. PR comment: When to use XML based format ACTION NDW

  10. REC planning
  11. WebArch books
  12. Review of current www-tag threads ACTION CL
  13. URIs for litterals
  14. URNs for namespaces
  15. TAG Issues
  16. rdfURIMeaning-39 ACTION DC
  17. RDFinXHTML-35 : Syntax and semantics for embedding RDF in XHTML. ACTION NDW, DC
  18. xmlProfiles-29 : When, whither and how to profile W3C specifications in the XML Family.

    RESOLVED: to close XMLProfile-29, withdrawing the request on XML Core WG

  19. (day 2)
  20. 5. TAG Issues
  21. 2.2.1 Media-Types Issues RFC3023Charset-21 ACTION CL
  22. 2.2.1 Media-Types Issues putMediaType-38 ACTION CL
  23. mediaTypeManagement-45 , 2.2.1 Media-Types Issues ACTION CL, SW
  24. 2.2.2 URI and Fragment Issues: httpRange-14 ACTION DC
  25. IRIEverywhere-27 ACTION RF
  26. fragmentInXML-28 ACTION CL
  27. metadataInURI-31 ACTION SW
  28. siteData-36
  29. xlinkScope-23
  30. XMLVersioning-41 ACTION PC, DC, NM
  31. abstractComponentRefs-37
  32. DerivedResources-43 ACTION CL
  33. Thanks to the host, adjournment

The following agenda were not discussed

Venue, Logistics

The meeting is in two facilities at the MIT Stata Center: room 262 Monday all day and Tuesday morning, and room 346 Tuesday afternoon.

Telephone access is through the Zakim bridge (+1.617.761.6200) using the normal TAG pass code, 0824#.


Convene, take roll, reivew records and agenda

irc notes by NM et. al. start 14:40:26

NW convened the meeting with all TAG members more or less present (SW by video etc.; see participants above). We reviewed the proposed agenda and moved a few things around.

We started to review the record of the 22 Nov 2004 teleconference but postponed approval until more of us had reviewed it.

Meeting Planning

We RESOLVED: to meet again 6 Dec, 13 Dec 20 Dec, and 3 Jan. NW gave regrets for 6 Dec. For 13 December, PC gave regrets and CL gave regrets due to vacation. CL noted a travel risk for 20 December. We RESOLVED: to cancel the 27 Dec 2004 teleconference.

ACTION CL: to cause draft of press release to happen. CONTINUES from 2004-10-07

Future Directions for WebArch, TAG

irc notes by NM et. al. start 14:53Z

We considered reviewing the list off issues we postponed until after webarch V1 and considering cleanup of webarch V1, but opted rather to discuss futre work at a high level, without constraining the discussion by either of those. PC noted the possible interaction between likely topics of work and votes for TAG membership.

TBL was positive about looking at RDF/SemanticWeb and said that doing Web Services would be appropriate, but expressed concern about the defacto architecture that that's coming, e.g. from corporate sources. NM said that those working on Web Services would benefit from the right kind of guidance on how to better leverage the Web Architecture and build scaleable systems; on the Semantic Web side, he said the TAG should not get too far out ahead of what widespread deployment validates. DC ask that the TAG "go to school", reading up on topics like information theory and discussing them with experts... having the Web Servcies Choreography WG deliver a presentation aimed exactly at the TAG audience.

CL suggested the interaction domain topics merit more attention than they have gotten. PC said the mobile web would be a really good area for attention, noting enthusiasm at the recent mobile web workshop in Barcelona. CL noted there are already some estimates that the mobile web user base is bigger than the desktop web user base.

TBL suggested different appoaches in different areas:

for voice
learning ("school mode") how the community has defined its arch, so that the TAG can just say how it fits in.
in web services
get seriously involved in WS addressing work as it is a crucial and undefined part. NM agreed WS addressing merits TAG attention.
in semantic web
try to extract the main lines from the existing specs and put them in persepctive
in mobile
hope they wok in a very arch-smart way, and keep in touch.

PC and DC discussed the border between quality-of-implementation issues and architectural issues in the emerging mobile platform.

CL noted the importance of tuning presentation of old architectural issues and solutions to new industry groups, e.g. to prevent telcos from making the "latin-1 is good enough" mistake that the web community has since learned from; CL noted there there is a standards body that does web standards for China and Korea and encouraged the TAG to get involved, suggesting that ignoring a single Chinese telco standard could seriously fragment the web. SKW said the telcos and mobiles have a major incentive to grow beyond flattening voice revenues. PC reported from that community an increasing focus on device independence. TBL suggested a more direct liaison to the OMA than the TAG currently has.

We went on to discuss the balance between talking and listening, writing, travelling, etc. PC noted that the TAG did less outreach in the recent six months than the previous six months, though our focus on review comments explains that to some extent. PC noted the possibility of meeting with each new W3C WG, perhaps at the W3C technical plenary.

NM suggested disconnected, peer to peer, and other non-traditional-web models as a focus of future TAG work; in particular

  1. disconnected operation
  2. 30% of internet bits are bit-torrent

A list of topics emerged from the conversation, as well as ways of working on them:

traditional webarch
continue to give talks; publish presentation materials (e.g. on W3C talks page) and videos of talks; teach courses; develop course materials. Work with groups (e.g. SC29 ISO MPeg working group) that seem to be deploying Web Architecture in places where it wasn't previously used as much.
learning how the voice working groups and community has defined its architecture ("school mode") so that the TAG can express the relationship to webarch V1.
web services
get seriously involved in WS addressing. Ask WS choreography to present.
semantic web
study information theory and economics. don't get too far ahead of what widespread deployment validates, but extract the main lines from the existing specs (@@hmm... what does that say about a way of working? was there really any sense of the meeting here, more than individual positions?)
encourage device independence, One Web; keep in touch. More dialog with Chinese, Korean standards efforts
punctuated connectivity
disconnected, occasionally connected, etc.
study the use of p2p protocols with the http namespace; promote research; look at RSS caching issues, next-gen email architectures, jabber

Advisory Committee Meeting Preparation

norm: Ian says that if we get stuff together by today, we get them in the packet

Above links are (1) slide proposal and (2) proposed written summary, both from Paul.

Now discussing written summary at

paul: I have some nervousness about what's stated about outreach. Is it OK?>

chris: yes

paul: this is more or less in the same form as previous reports

norm: looks fine to me

<DanC_lap> (bummer the Basel record wasn't clear enough; I thought we empowered PaulC to deliver the summary directly to the AC meeting materials without the TAG in the critical path)

stuart: as I said on list, would favor a bit on future directions

norm: seems more appropriate for presentation than summary

<timbl> "The

stuart: will go with flow

<timbl> TAG also moved the following issues to a deferred state since they are

<timbl> awaiting action from another group"

tim: I'm nervous about pending vs. pending

someone: that's from the minutei think we should substitute :-)

<Chris> origin of these terms is the exit software that Ian was using

<DanC_lap> it's clear enough to me: "TAG also moved the following issues to a deferred state since they are

<DanC_lap> awaiting action from another group"

Note to those reading the pretty printed copy, the above quote from Tim should read: "The TAG also moved the following issues to a deferred state since they are

<timbl> awaiting action from another group"

<Chris> and that propogates into the issues list

<scribe> ACTION CL: to turn proposed summary into HTML

Now discussing proposed slides from Paul at:

<DanC_lap> slides seem good. themes: people (membership, election coming...), proposed REC

noah: we should mention correct nomination deadline of 12/14

tim: AWWW is generally not an appropriate normative reference, because we provide very little in terms of prescribed grammar, protocol, etc.

paul: I'd push back. Things like i18n are also very horizontal and are referenced normatively.,

<Norm> zakim wouldn't let me "ack" you DanC_lap

paul: how will community know where AWWW stops and specific specs start? It's a recommendation. It talks about principles. Looks & feels like QA framework.

tim: how does that affect the way you quote it?

paul: I'll answer with respect to something you might discuss tomorrow. QA framework mandates in each spec a section on XXXX. Can't you make a normative reference to QA framework for that.

Roy Fielding arrives.

paul: I'm saying people will be confused?

tim: are you saying quoting normatively or obeyed?

<Zakim> DanC_lap, you wanted to say (a) yes, we're happy for folks to cite webarch normatively if they find it useful (b) we're happy for folks to cite it in comments on other specs but

paul: let me restate your position, Tim. AWWW would often influence other specs, but not by making normative reference.

tim: only place I could see that happening is when we define a term like information resource
... still, our glossary remains a bit informal for that purpose

chris: I disagree with Tim. I think other specs can/should refer to AWWW normatively. E.g. statement in SVG that "we believe that nothing here conflicts with AWWW".

tim: hmm

chris: make sense?

tim: maybe?

<Zakim> Chris, you wanted to speak about normative ref to webarch

<Norm> a?

noah: points to his email

"A correction becomes normative

-- of equal status as the text

in the published Recommendation --

through one of the processes

described below."

<Chris> in other words, we were asking for people to point out conflicts if they found them. In that sense it was normative

<Zakim> noah, you wanted to discuss my note on normativity

<timbl> Noah: [defines normative in the sense "Love me, love their awww"]

<Zakim> Stuart, you wanted to say that the value of putting AWWW on Rec track is the concensus process.

noah: so, I think we could go either way. Some preference for allowing normative references.

stuart: the value of putting AWWW on Rec track is the concensus process
... in our charter we have the term "Architectural Recommendation". Is there a class of docs in the W3C that is more like arch documents, and should the process document say more about them?

<Zakim> DanC_lap, you wanted to say (a) yes, we're happy for folks to cite webarch normatively if they find it useful (b) we're happy for folks to cite it in comments on other specs but

<Stuart> +1 to Dan

<Norm> +1 to DanC

dan: we crossed the bridge a long time ago in allowing normative reference to things that are not testable. We should allow normative references, but there's no institutionalized enforcement of webarch-conformance, other than normal peer comment processes (where the TAG may occasionally play the role of peer)

noah: fine with me

tim: doesn't say one way or the other that tag as a group has a certain organizational role and influence

norm: right, we don't need to say that there
... I think the worry was not "can you make a normative reference" but rather "do you have to obey it"?

tim: typically, "no you don't have to obey it, but you have to have a good reason"

<DanC_lap> i.e. "you have to answer comments"

paul: Some scepticism. For past two years we've struggled to speak in lower case letters. Nobody believes it.

<timbl> DanC: well, it is the consensus of a large group of people now, and soon the AC too, so it deserves the respect of a W3C rec when a w3c rec.

<timbl> Noah: I don't see how anyone can read a statement as we ofetne say a la "we thing this is a good idea" as being an absolute requirement.

<timbl> Noah .... It is a loittle weird totlk about obeying the document where it doesn't even insist on anything

<timbl> Norm: People still feel sometim,es that "you should consider..." is too much of a constraint.

<timbl> Noah: "MUST" isi used sparingly in awww.

tim: diminishing returns on this?

chris: I think I have what I need.

paul: Is Chris generating slides?

<timbl> (Danc, there was push back on our not presenting anything from Ian and SteveB)

<DanC_lap> (yes, I saw the pushback. what I didn't see was our getting convinced)

<scribe> ACTION CL: to prepare slide HTML based on input from Paul

dan: you asked what will come up in our session. I think XLink will.

paul: what do you think will be the way it will be raised?

norm: are you aware that core working group is "picking up" XLink to do an XLink 1.1 in order to fix a small bug.

noah: it will retain the characteristics that have "bothered" some people?

norm and chris: won't fix the concerns of the HTML working group, but will meet the expressed needs of SVG and DocBook

stuart: any dialog with the hypertext coordination group on this?

norm: this was given to a linking task force that Liam Quinn is leading, but core seems not to be waiting for this.



noah: on versioning, should we ask David Ezell to dial in tomorrow to explain schema use cases?

norm: probably not needed tomorrow, and our planned afternoon time doesn't line up with his availability in any case.

<Chris> 16:30 - 17:15 Technical Architecture Group

<Chris> [Discussion] [slides]

noah: I'll tell him no thank you.

norm: anything else on AC prep

<Chris> Since the May 2004 AC

<Chris> meeting the TAG has:

<Chris> The TAG has spent most of the time since the May 2004 AC

<Chris> meeting dealing with Last Call issues, however the TAG has:

<Chris> agreed? ok


Lunch Break...

<Chris> Action completed: htmlize AC summary

<Chris> W3C Technical Architecture Group Summary

Tech Plen planning

<Chris> Scribe: Chris

<Chris> Paul: Suggest TAG should ask for a slot, decide what it wants topresent. past sessions well received

<Chris> Norm: Yes, in past this worked well, we should do that again

<Chris> Roy: Timing is a little difficult, due to election churn....

<Chris> Paul: Plan is to have old and new people at the first meeting after an election

<Chris> Paul: Could do a topic ex E&V where Tag, schema, etc were the pannelists

<Chris> Norm: What are our future plans, TP might influence that direction

<Chris> TimBL; Should not be afraid to argue technical things , open cans of worms

<Chris> DanC: A play depicting the history of HTTP range-14

<Chris> Norm: drama might be good :)

<Chris> DanC: prefer topic based slots to group based ones

<Chris> TimBL; interested in mor egeneral topics also

<Chris> Noah: Is there the usual planning committee?

<timbl> (see )

<Chris> Noah: Any more good, deep parts of WebArch that we could talk about?

<Chris> Paul: There is already a WS-Addressing meeting at TP

<Chris> Noah: Email preceeding email is good to get folks up to speed

<Chris> Paul: Perhaps discuss with DO tomorrow

<Chris> Noah: also depends what they are naming at what granularity, eg a port number ....

<Chris> DanC: Looked at spec, some parts are opaque

<Chris> TimBL: have had offline discussions to explain a bit

<timbl> Endpoints slide

<Chris> Paul: So, should I reply to Steve sayingyes, an E&V slot was endorsed by TAG

<timbl> ^ Slide overveiw of the WS adderssing endpoint issue

<Chris> DanC: so, what is the TAG position on E&V, what is the elevator speech/ Can we narrow the focus?

<Chris> Paul: Can narrow to the Schema aspect, Schema 1.0 and 1.1

<Chris> Noah: this should really be discussed tomorrow in the agenda slot allocated to it

<Chris> DanC: OK with the topic, details need to be worked out

<Chris> Norm: happy with that response too

<Chris> Norm: any objections?

<Chris> (none)

<Chris> (Paul sense email responding to Steve)

PR comment: Opera on 4.3 (Separation of Content, Presentation, and Interaction)

<Chris> Dan: is this editorial

<Chris> Norm: agree its editorial, approve

<Chris> Roy: me too

<Chris> Dan: fine by me

<Chris> Approved to make this change to WebArch

PR Comment: Nokia on "namespace document"

<Chris> is it editorial?

<Chris> Norm: next thing - changes to glossary. is it editorial?

<Chris> Dan: commentor seems to think not

<Chris> Norm: Not substantially different

<Chris> Norm: discussed at last weeks telcon. if a ns uri identifies an IR then that Resource is a namespace document

<Chris> Chris: That change makes if clearer, for me?

<Chris> ACTION NDW: Norm respond to commentor re defn "namespace document" in glossary

<Chris> Noah: Generally agree but tricky in one respect

<Chris> Noah: so if its not an IR there is nothing to retrieve? (some nods) but we don't actually say that

<Chris> Noah: so in other cases, all bets are off.

<Chris> DanC: We say it should be an IR

<Chris> Noah: so people miht be tempted to have physical resources and ns uris

<Chris> Noah: OK for us to be silent on that, but it is a point of confusion

<Zakim> timbl, you wanted to ask whether TAG members have suggestions for general topics for TP

<timbl> A "namespace document" is an Information Resource, whose URI is the same string as the namespace prefix, and whose content describes the namespace.

<timbl> A "namespace document" is an Information Resource, whose URI is the same string as the namespace URI, and whose content describes the namespace.

<Chris> Noah: prefix is wrong there

<DanC_lap> "whose content" should be phrased using representationg

<timbl> A "namespace document" is an Information Resource, whose URI is the same string as the namespace URI, and which describes the namespace.

<timbl> You should have one.

<Chris> Noah: this says if you don't provide an IR hten you can't call it a NS doc

<Chris> Chris: ok, so a dog is not a ns doc. Good

<Chris> Roy: we decided this last week

<Chris> Norm: ok so anyone move to reopen?

<Chris> (no-one)

<Chris> Fine so we stick with original wording "If blah" as recorded in 22 Nov minutes

Character encoding from Eric Bruchez

<Zakim> DanC_lap, you wanted to lob the xlink grenade in this context cuz, hey, I'm completely insane and to note caldav with urn: namespaces

<Chris> DanC: to clarify this is an agenda request, not something on crit path for PR

<DanC_lap> (caldav stuff )



<Chris> thanks

<timbl> "Locks are indispensible when multiple authors may modify or create the same resources" caldav caldav

<Chris> summarises the current situation re RFC3023

<Chris> Roy: response should be yes, 3023 is wrong and this conflict is being resolved by editing 3023

<Chris> ACTION CL: respond to Eric about this

<Chris> +1s from Norm and Dan

<Chris> Roy: Tim Bray would have plus oned as well

When to use XML based format

<Chris> Yuxiao Zhao


<Chris> Point one is evental need, immediate realisation of a future extensibility point

<Chris> point 2: explain more

<Chris> on point 4 do we not give examples of audio and video as not xml suitable?

<Chris> "not universally applicable"

<Chris> Point 1 we adress. Point 2 not sure. Point 3 not clear its a good reason and point 4 is covered already

<Chris> on point 3, xml can encode a range of things from higly abstract to highly presentational

<Chris> ACTION NDW: Norm respond to commentor

REC planning

<Chris> Norm; this is all the comments arising form PR

<Chris> Dan: What is the plan for making a REC draft?

<Chris> Chris: Whatare the other 2 talking points

<Chris> The third one is the community review W3C process etc

<Chris> Paul" documenting the pronciples on which thwe web has been built helps other people grow the web

<Chris> Paul: Rude Q&A - what next?

<DanC_lap> (I'm OK with Volume 1)

<Chris> Tag intends to further develop ..... architectiral questions and issues that have broad impact on future of web

<Chris> Dan: Insert general W3C message

<Chris> Chris: the 'what changed, so what' question

<Chris> Noah: Weeb bilt of small specs working together, what was folklore is not set down clearer, so specs will work together better

<Chris> Paul: Jorney equally important as result - engaging web community

<DanC_lap> yes... the consensus/journey aspects might merit 2 points, not just the usual 1 about w3c process

<DanC_lap> (list workshops? lifesci? mobile?)

<Chris> TimBL: Discussions involved many WGs and helped them work together in compatible ways. Mobile Web is particularly worth mentioning

<Chris> Paul: check workshops form last few months - MWeb, CompDoc etc

<Chris> Noah: reaches a wider, non priesthood audience

<Chris> Noah: consciousness raising, wider audience

<Chris> Paul: WebArch plus more stuff from findings would make a nice softcover book

<Chris> Paul: some folk wil not read the webarch as is, rewriting in a more accessible way

<Chris> DanC: Interesting

<Chris> Norm: for a later Agenda item

<Chris> Paul: Are we expecting testimonials from everyones company?

<Chris> Yes

<Chris> WBS form has the 'promotion' part

<Chris> Chris: Roy, are you putting something in on your own behalf?

<Chris> Roy: yes


WebArch books

<Chris> Dan: request froma publisher,more than a year ago.

<Chris> time pressures, plus my view vs tag view

<Chris> Chis: i was also contacted, prefered to wait till it was done

<Chris> Roy: group project is a big time sink

<Chris> Separate chapters by different people isn't that great an idea.....

<Chris> Paul; My standard response is "no" its less than minimum wage so the benefits are purely getting ones name on the cover

<Chris> Paul: OK to do if being paid, but enough other things to do

<Chris> Noah: A few authors make money, often the book just sinks though. Concern about auto adding new people to author list.

<Chris> Noah: Some specs look impemetrableso the authors get to write a book

<Chris> Noah: OK with other people doing their own take on the wen arch

<Chris> Noah: Annotated xml spec added good value

<Chris> Roy: There are http books that are 70% copied out spec

<Chris> Roy: A W3C Recs book might be interesting, just republished

<Chris> TimBL: Re-launch W3J?

<Chris> TimBL: MIT press publication of W3C workshops?

<Chris> Roy: XML Recs - the complete set. Colectors special edition

<Chris> Dan: Some communitoies we don't reach because they read paper and we don't do paper

<Chris> DanC: what about interviews?

<Chris> TimBL: unhappy to see personal comment mixed with webarch

<Chris> Noah: can direct people to www-tag and answer questions there

<Chris> Dan: more interested in outreach rather than personal comment

<Chris> Paul: Giving a 1.5 hour talk and print 250 copies of Webarch at university. getting it into the curriculum

<Chris> ... in the context of a distributed systems course

<Roy> Ric Holt at U Waterloo:

<Chris> (tag discussed further outreach opportunities)

4. Review of current www-tag threads

<Chris> Paul: deep linking and linking into resources

<Chris> Chris: deep linking vs 'bandwidth theft'

<DanC_lap> (see earlier request for discussion of p2p influence on http)

<Chris> Chris: also the deep linking transclusion issue - copyright etc


<Chris> Athens olympic site

<Chris> Noah; we can't chase all the people that did not read the finding. On the other hand, high profile cases can help ensure uptake

<Chris> (tag discusses lack of cute baby seals to power a hall of fame approach)

<Chris> We se no new evidence here and the finding still stands

<Chris> referer tactic and bandwidth hteft - consistent with 'technical not legal' approach of the finding

<Chris> ACTIION: Chris produce draft revised finding on deep linking

<Chris> ACTION CL: produce draft revised finding on deep linking

<DanC_lap> (pointer to where the SMIL WG says "don't address into media files"???)


<Chris> part of the issue is use of fragment identifiers and adressing sub resources

<DanC_lap> (I'm having trouble relating what Chris is saying to what Concolato is saying in 0046)

<Chris> part of it is, what is the nature of the resource

<Chris> quote "My suggestion is to specify that the audio element should handle audio

<Chris> streams only, and the video element video streams only. This means

<Chris> removing (or deprecating) the audio related attributes from the video

<Chris> element. It also means that the xlink:href attribute of those elements

<Chris> have to be precise enough to identify one stream (in a container file,

<Chris> on a server, ...) maybe using fragment identifiers. The mimeType

<Chris> attribute in this case would describe the type of media stream and not

<Chris> the type of container."

<Chris> responses


<Chris> and


<timbl> (I Just added Athens Olympics to my own personal hall of flame

<Chris> Norm: Email from Jack says that SMIL WG knows they need to get to this but have not yet.

<Chris> Summary TAG does not see a big architectural issue here and suggests further coordination with SYMM WG

URIs for litterals

<DanC_lap> (topic: Benjamin)






<paulc> and XML Schema Libraries and Versioning: The UBL Case at


URNs for namespaces

<Chris> (discussion on URNs and resolvability)

<Chris> Noah: An ordinary person can't really get from our finding why using a URN is not a good idea. In particular, subtleties of whether an http URI is always resolved by HTTP

<Chris> DanC: they do actually track these URNs to ensure non overlap and the tracking device is a Web page so in effect there is an http URI for these

<Chris> TimBL: HTTP is a namespace, we have the power to change the protocols

<Chris> (TAG was visited by a representation of )

<Chris> Noah: prefered result is to look at p2p in the http namespace. one answer is roys, use HTTP and upgrade later. HTTP namespace is not restricted to the HTTP protocol

<Chris> Noah: If Tim is right and we can deploty a range of protocols in this namespace, my comfort level goes way up about telling people to se http namespace

<Chris> Noah: If people choose URN to avoid being tied to a given protocol, then telling them this now would help

5. TAG Issues

<Chris> * Stuart's TAG Issues grouped by theme

<Chris> o Which items go on the bottom?

<Chris> o Review of issues list/future planning:

<Chris> + first batch, second batch(es)

<Chris> o Review of draft findings:

<Chris> + xmlProfiles-29

<Chris> + Authoritative Metadata resolves putMediaType-38?

<Chris> + mediaTypeManagement-45

<Chris> + Other draft findings...

<Chris> Paul: Issues list is not maintained

<Chris> Norm: take issues.html and rip out the database parts, flatten, and date it

<Chris> Paul: its very misleading currently

<Chris> DanC: not sure where it is incorrect right now

<Chris> (some consulting of the issues list)

<Chris> Paul: links to some findings are not to latest one

<Chris> Norm: not maintainable without more staff resource (general agreement) so change the page, put a last mod date

<Chris> Chris: perhaps put each issue in a separate page, all linked from one summary table

<Chris> oops but fragments can't be redirected to separate pages

<Chris> Paul: still not clear what we are actually doing

<Chris> DanC: if a finding was discussed, add to the page

<Chris> Chris: perhaps start with

<Chris> Paul: happy to scale back the level of information, as long as what is there is up to date and accurate and reliable

<Chris> Noah: issues might get more important now AWWW is out the door and shapes the next phase of work

<DanC_lap> (I hope to add a link from each issue to a search for that issue in the archive, ala

<Chris> tes back




<Chris> status is: nothing is happening

<Chris> TimBL: overtaken by events

<Chris> Norm: was one approach to http-range14


<Chris> Timbl: "RDF documents use URIs as identifiers for things including for

<Chris> relations. An RDF statement "S P O" means that a given binary relation

<Chris> identified by P holds between to things identified by S and O. (S, P

<Chris> and O are URIs)"

<Chris> Disagreeing with dereferencing P means don't use P

<Chris> DanC: Meanwhile W3C has 2 different definitions of rdfs class

<Chris> TimBL: not sure they are inconsistent

<Chris> TimBL: Suggest leaving on back burner, interesting, leave for now. ArchDoc contributed a lot but does not really address RDF yet

<Chris> TimBL: expect to see movement on this for WebArch 2, is a prerequisite

<Chris> paul: Disagree. TAG should not do this, why isn;t this something that the SW WGs fix themselves?

<Chris> Paul: Why not do this for other areas, eg Web Services

<Chris> DanC: (gives WSDL example ... some discussion)

<Chris> Noah: early bound vs late bound checking.

<Chris> Paul: (DOS attack from malformed SOAP messages)

<Chris> Norm: meaning of URIs in RDF is RDFs problem. OTOH, if RDF says one thing and WS says another, everyone looses

<Chris> TimBL: Job of TAG is to glue things together, ensure things work together

<Zakim> timbl, you wanted to say why we need to stitch OWL to URI

<Chris> TimBL: owl people saw no vale in dereferencing, need to explain this to them.

<Chris> Paul: AWWW says to use XML instead of binary, but instead of 'no binary' we spun it off to another group to study in depth. Same here, surely?

<Chris> Paul: TAG wrote a taxonomy to describe the problem space

<timbl> OWL people didn't sign up to the 'meaning' of a URI being connected to what you get when you dereference it.

<Chris> Noah: sort of with you here, but maybe we should pass it back to them. if they think their use of URIs is disconnected from everyone elses, ask them to justify that

<Zakim> DanC_lap, you wanted to agree that as stated, it's about URIs in RDF; either we should hand it to the SemWeb Best Practices WG, or we should re-state it to apply to abstract

<Chris> Norm: Clear we can't close this now. Is it closable short term or long term.

<Chris> DanC: its stated as an RDF problem. If its only an RDF problem, not a TAG issue. If its also a WS problem then there is TAG relevance

<Chris> Noah: Or we could keep it open and pending, we want them to track

<Chris> DabC: No, I was proposing to close it not move it to pending

<Chris> ACTION DC: ask SWBP to take the issue

<Chris> Norm: If they will take the issue, then we can decide what to do

<Chris> DanC: so three options, will they take it if the tag keep s it open, would that take it and allow TAG to close it, or will they not take it

<Chris> Paul: Looks like we need a requirements document for the AWWW. We can't design on the fly without aplan in place.

<DanC_lap> (the part of W3C that developed requirements process is... not something timbl encouraged, I think)

<Chris> Norm: not comig to closure here. Prefer to see the outcome of Dans action

<Chris> Paul: Ask them to rewrite in current AWWW terminology

<Chris> TimBL: when we started TAG, we took issues and once we had some, broke them into ones to solve now and one to defer. That outline view was the requirements document

<Chris> TimBL: needs a f2f meeting and a whiteboard

<DanC_lap> (as an agenda request, I concur)

<Chris> Noah: good way to prioritize


<DanC_lap> ACTION DC: make sure issue raising message is linked from issue 39

<Chris> That is the original statement of thre issue that Dan needs to point to

RDFinXHTML-35 : Syntax and semantics for embedding RDF in XHTML.

<Chris> DanC: Remember I presented GRDDL before

<Chris> DanC: at last TP, Mark Birbeck presented another RDF syntax from the HTML WG

<DanC_lap> slides

<Chris> DanC: David Wood presented at XML 2004

<Chris> in particular

<Chris> DanC: so, the TAG finding needs to be updated to reflect this

<Chris> Oh - there is no actual finding. Maybe don't need one here. Already solved. Question went away

<Chris> Chris: So is this only for HTML (because of the 'ignore unknown tags'/'hide in attributes' design'

<Chris> Norm: why not just say rdf|* { display: none}

<timbl> rdf/eh

<timbl> t-15?

<Chris> # If a user agent encounters an element it does not recognize, it must process the element's content.


<Chris> 3.2. User Agent Conformance

<Chris> as opposed to.....

<DanC_lap> ah, indeed, chris. interesting.

<DanC_lap> sigh. how did that get thru CR?

<Chris> still looking for the HTML4 part

<Chris> but it was non normative

<Norm> XML 2.0:

<Chris> and is not in the HTML 4 conformance section

<Chris> I have pointed this out at least twice before

<Roy> RDF/A uses qnames in content == evil

<DanC_lap> sorry for being dense, chris.

<Chris> sorry for getting annoyed. just felt i had explained it all before

<timbl> "If a user agent encounters an element it does not recognize, it must process the element's content."

<DanC_lap> I'm pretty familiar with what HTML 4 said, and yes, it was non-normative.

<timbl> Should we raiseit as a problem with XHTML1 extensibility?

<Chris> Norm: Concernover loss of namespace declarations

<Chris> DanC: if there are XML Queries that will break here ....

<Chris> TimBL: doesn't it need a schema?

<Chris> Noah: no, could be declared in the query

<Chris> Noah: queries will not preserve namespace prefixes it was not aware it needed. But then qnames will break

<Chris> TimBL: and we are back to magic prefixes

<Chris> Paul: So we need a liaison here between Query and HTML

<Chris> Norm: Should this wait for last call?

<Chris> Dan, TimBL: No!

<Chris> QName in Context finding could show that qnames have the following problems, and avoiding it means you don't hit the problems. At the expense of big URIs

<Norm> ACTION NDW: Norm to update QNames in content finding to contrast XSLT and XQuery support for namespace delcarations that used by qnames in content

<DanC_lap> ACTION DC: comment on qnames in content in RDF/A, based on updated finding

<Chris> Noah: finding may need to point out the range of ugliness of qnames

<Chris> TimBL: mapping was not defined in the XML Namespaces spec

<Chris> Paul: its already published as final, so we need to republish

<Chris> Norm: yes

xmlProfiles-29 : When, whither and how to profile W3C specifications in the XML Family.

<Chris> tag groans

<Chris> Norm: TAG asked Core to do a Rec track document here

<Chris> Norm; Core feels it could do a WG note but not a rec track document - not enough value

<Chris> Norm: could be XML except a DOCTYPE.

<Chris> replaces one production.

<Chris> Noah: current processors can't be used, too heavy ....

<Chris> Norm: people want a soap like subset, Core feels this doesn't make a lot of sense

<Chris> Norm: But TAG asked for a Rec track document, do we really need one

Clarification: Noah was saying we need to understand why you would want a profile defined, and was speculating that core was assuming that a suitable profile would encourage common use of processors for the subset.

<Chris> DanC: Sympathetic, no urgent need for it. No architectural reason for it to exist

<Chris> DanC: is a readable subset, XML slimmed down with all the DTD cruft taken out

FWIW: I am less convinced than many others that the requirements are common across users. I'm also unconvinced that optimized SOAP processors, for example, will necessarily share parsers with other applications.

<Chris> Paul: parameter entities double implementation time

<Roy> Chris: would the content be marked as somehow different from "real" XML

<Chris> Chris: The content would not be distinguished in any way, how does a processor know it conforms and not to add forbidden doctype eg an entity declaration

<Chris> Norm: It would not

<Zakim> noah, you wanted to say use of common processors is overrated in high-perf situations

<Chris> Noah: Assumption is that the soap subset is valuable. maybe it is, maybe not.

<Chris> Noah: high performance soap processors are highly tuned. Not clear that for oither uses there is enough commonality. Needs to be demonstrated, not assumed

<Chris> Noah: currently you know that it conforms to the soap subset because its a soap envelope....

<Chris> Norm: if an outcome is that TAG reconsiders whether to ask Core to do this I would be really pleased

Noah says +1 to Norm on that.


<Chris> Norm; i was concerned about fractionally different subsets, but that does not seem to be happening

<DanC_lap> (in this case, paul's spelunking is already reflected in the issues list)

<Chris> Paul: Future of XML workshop in next 6 months or so might conclude that a larger spec (including XML namespaces etc)... also XBC will report then. Uptake of XML 1.1.

<Chris> Paul: TAG might find an audience for a broader answer

<Chris> Norm: So it would make sense for the Core WG to sit on that for a while

<Chris> Paul: If the workshop does take place on schedule

<Chris> Dan: has anyone promised this?

<Chris> Chris: not until XBC is done

<Chris> Dan: will people get on a plane for such a workshop?

<paulc> Member only:

<paulc> Member only on XML 1.1:

<Chris> Chris: people actually doing non-ascii element names *will* run into this problem

<Chris> Straw poll: do we close xmlprofiles-29 and send message to Core saying its no longer required

<Chris> Yes: norm, roy, noah, paul, chris, tim, dan

<Chris> unanimous

<Chris> Paul: Any objections to closing XMLProfile29 and witdrawing the request on Core

<Chris> No objections

RESOLVED: to close XMLProfile-29, withdrawing the request on XML Core WG

<Chris> Noah: Are we going to pick this up tomorrow?

<Chris> yes

<Chris> </meeting>

day 2: 30 Nov 2004

5. TAG Issues

<paulc> TAG issues grouped by theme:

<DanC_lap> PaulC: which issues shall we discuss next? Stuart: I'd like to discuss metadataInURIs 31


<DanC_lap> PaulC observes that 31 is in the "2.2.2 URI and Fragment Issues" cluster of

<DanC_lap> PaulC observes requests jive with

2.2.1 Media-Types Issues RFC3023Charset-21

<DanC_lap> PC: outstanding actions here?

<DanC_lap> CL: just the long-standing action to edit the revision


<DanC_lap> subject: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

<DanC_lap> CL: there's pushback on the use of XPointer

<DanC_lap> ACTION CL: explain how just using the RECcomended parts of XPointer isn't too much of a burden in RFC3023

<DanC_lap> CL: ... charset...

<DanC_lap> SW: I found Martin's distinction between use in registration docs and use in exchanged documents useful

<DanC_lap> CL: I don't see how it helps to require documenting and implementing it but not using it


<Chris> see also

<Chris> In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the

<Chris> ation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing

<DanC_lap> " In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing."

<Chris> Roy: Existing 3023 says must, so we went to SHOULD NOT; if it had not, we would have said MUST NOT

<DanC_lap> RF: if not for the "providers MUST..." in RFC3023, we'd have said "MUST NOT".

<DanC_lap> CL: revising the finding along those lines seems like a good next step

<DanC_lap> PC: there may be knock-on effects on webarch

<DanC_lap> DC: I don't see an opportunity to do that before REC

<DanC_lap> PC: no, but eventually

<DanC_lap> CL: ... charset... local disk... xml processor...

<DanC_lap> ... transcoding proxy

<DanC_lap> ... +xml

<DanC_lap> PC: in sum, CL is continuing to negotiate changes to 3023 ...

<noah> NM: I asked whether we were going so far as to encourage transcoding of XML into different encodings, while revising the XML declaration appropriately.

<Stuart> Two questions: 1) Is text/*+xml allowed (discouraged but allowed) 2) Should charset be used with an instance of text/*+xml if it occurs however discouraged?

<noah> NM: The answer I got was: "IF you choose to transcode, THEN you must keep the decl in sync"

<Chris> Chris: not encouraging, but recognising that it happens and also, that the +xml convention has value here for unrecognized media types

<DanC_lap> PC: I subscribed to ietf-xml-mime. how many others? CL

<noah> NM: I agree with that, but raised another point: "We should note that such transcoding has costs for other reasons: there are situations in which I depend on my XML files being byte-for-byte unmodified (e.g. CVS diffs)."

<DanC_lap> Re: MIME Type Review Request: image/svg+xml

<DanC_lap> CL: yes, I'll let the TAG know when the RFC3023 revision merits TAG review or discussion


<DanC_lap> Fw: XML media types, charset, TAG findings Fri, 08 Oct 2004 10:48:00 +0900

<Chris> That summarizes what I have been saying

2.2.1 Media-Types Issues putMediaType-38

<DanC_lap> CL: oh yeah... I had an action here...

<Chris> pointer to the list Paul is projecting?


<Chris> ACTION CL: explain why resources that have further server side processing (includes, php, asp etc) might want to have different media type when placed on server and when retrieved from it

<DanC_lap> DC: likely for monday's telcon? CL: maybe. 1/2hr email, provided I find the 1/2hr...

<Chris> its a half hour email thing, well try to do in next few daya

mediaTypeManagement-45 , 2.2.1 Media-Types Issues

<DanC_lap> reviewing ACTION CL: draft finding on 45

<Chris> text from minutes

<DanC_lap> NM asks about raising issues; several encourage him to raise them in www-tag

<Chris> Chris: note to self, also discuss impossibility of media types for combinations of different document formats (xhtml+matml+svg+etc)

<DanC_lap> NM: things like application/soap+xml seem to be stretching MIME... people want this mix-in...

<Chris> Chris: there was asuggestion to do a three way hierarchy, like application/foo/xml or another suggestion was xml/image/foo

<DanC_lap> ... but if I really want to say "this is a SOAP purchase order" the 2-level system doesn't accomodate it well

<Chris> +xml precludes adding a +somethingelse

<DanC_lap> NM: decisions like "don't use ..." seem to be made on-the-margin

<DanC_lap> PC asks about the number of +'s allowed

<DanC_lap> PC: does RFC3023 restrict it to just one + ?

<DanC_lap> NM: I think so

<DanC_lap> NM: is it better not to raise an issue until there's a constructive solution in sight? I wonder, sometimes.

<DanC_lap> RF: there's a lot of aspects of media types that suggest "let's redesign the whole system..."

<DanC_lap> ... [missed]

<DanC_lap> PC: why isn't that[?] a comment on RFC3023?

<DanC_lap> RF: ... image/* is a whole bunch of unrelated formats; media types are a processing declaration more than a format declaration.

<DanC_lap> ... every text/xml thing is also a text/plain thing, but the difference is how you process it

suggested global issue: RethinkingMediaTypes?

<Norm> I sometimes worry about the whole media type/fragment identifier tangle of issues

<DanC_lap> CL: there was discussion of application/soap/xml , which is hierarchical, but...

<Chris> ... but if you extend it fiurther, is application/spap/cml/signed the same as application/soap/signed/xml ?

<DanC_lap> DC: this seems like issue 45, to me

<DanC_lap> [this = NM's questions]

<DanC_lap> NM: I'm glad to work with Chris on this

<DanC_lap> SW: how does this relate to compound documents?

<DanC_lap> CL: yes, quite... the html/svg/mathml 2^N stuff...

<Chris> PC: the 2^n+1 problem

<noah> FWIW, I think DC has been proven write. 3023 speaks of a suffix of +xml but does not outright prohibit additional "+" signs by my reading. Hang on, I'll copy some pertinent text.,

<DanC_lap> SW: the compound documents WG seems relevant here


<noah> When a new media type is introduced for an XML-based format, the name

<noah> of the media type SHOULD end with '+xml'. This convention will allow

<noah> applications that can process XML generically to detect that the MIME

<noah> entity is supposed to be an XML document, verify this assumption by

<noah> invoking some XML processor, and then process the XML document

<noah> accordingly. Applications may match for types that represent XML

<noah> MIME entities by comparing the subtype to the pattern '*/*+xml'. (Of

<noah> course, 4 of the 5 media types defined in this document -- text/xml,

<noah> application/xml, text/xml-external-parsed-entity, and

<noah> application/xml-external-parsed-entity -- also represent XML MIME

<noah> entities while not conforming to the '*/*+xml' pattern.)

<Chris> "A Compound Document is the W3C term for a document that combines multiple formats, such as XHTML, SVG, SMIL and XForms. The W3C Compound Document Formats (CDF) Working Group will specify the behaviour of some format combinations, addressing the needs for an extensible and interoperable Web."

<noah> Also: "This document recommends the use of a naming convention (a suffix of

<noah> '+xml') for identifying XML-based MIME media types, whatever their

<noah> particular content may represent. This allows the use of generic XML

<noah> processors and technologies on a wide variety of different XML

<noah> document types at a minimum cost, using existing frameworks for media

<noah> type registration.

<noah> Although the use of a suffix was not considered as part of the

<noah> original MIME architecture, this choice is considered to provide the

<noah> most functionality with the least potential for interoperability

<noah> problems or lack of future extensibility. The alternatives to the '

<noah> +xml' suffix and the reason for its selection are described in

<noah> Appendix A."

DC: I think it will be nifty if CDF presented their requirement document to TAG

<DanC_lap> DC: "compund documents" is a huge design space. I'm surprised W3C chartered a WG with a problem that big. I'm interested to have them present their requirements doc to us

<noah> See above...they really mean use of multiple namespaces that are designed to be mixed and matched.

<Chris> * Specifications for combining W3C technologies, such as SMIL, SVG and XML Events, with XHTML by reference.

<Chris> * Specifications for combining W3C technologies, such as XHTML, XML Events, CSS, SVG, SMIL and XForms, into a single document by inclusion.

<Chris> * Specifications for combining W3C technologies, such as SMIL, SVG and XML Events, with XHTML by reference.

<Chris> * Specifications for combining W3C technologies, such as XHTML, XML Events, CSS, SVG, SMIL and XForms, into a single document by inclusion.


<noah> There's good reason to debate the pros and cons of W3C having a working group in that area, but it's a very narrow slide of what I consider compound documents.

<paulc> 1. grounded in good practise 2. make it short

<paulc> Dan C suggested a finding on mediaType Management-45 should do the above two points

<DanC_lap> short ~= 5 pages

<DanC_lap> ACTION SW: coordinate with CDF WG. e.g. requirements presentation plenary week

[note paulc comments were actually paul minuting DC comments]

2.2.2 URI and Fragment Issues: httpRange-14

<DanC_lap> of

<DanC_lap> reviewing ACTION DC: with Norm, develop a finding on httpRange-14 starting with the HashSlashDuality text

<DanC_lap> NDW: I've done a little work on that

<DanC_lap> ... since preempted by webarch work

<DanC_lap> NDW/DC: delivery to tag late Jan is our best guess.

<DanC_lap> ACTION DC: update 14 in the issues list to put in on an agenda in late jan 2005


<Chris> Proof that the split we asked for happened



<DanC_lap> RF: I suggest that this should be marked pending IETF completing IRI spec [something] which is almost done

<Chris> Under normative references

<Chris> I-D IRI

<Chris> Martin Dürst, Michel Suignard, Internationalized Resource Identifiers (IRIs), Internet-Draft, September 2004. (See [NOTE: This reference will be updated once the IRI draft is available as an RFC.]

<Chris> PC: Schema has anyURI that is defined in terms of XLink

<DanC_lap> PC: current state is anyURI type in XML Schema...

<Chris> PC: XLink defines some of IRI

<Chris> PC: Quaery 1.0 xslt 2.0 xpath 2.0 (the qt specs) all inherit this

<Chris> CL: so there is already a support of a subset of IRI

<Zakim> DanC_lap, you wanted to note TimBL's questions

<DanC_lap> DC: to summarize: are there 2 spaces, or one space with 2 encodings?

<DanC_lap> SW: I've asked MD and found his answers somewhat unsatisfying... he seems to say "both"

<DanC_lap> CL: both seem to be useful...

<DanC_lap> RF: I'm unlikely to read the IRI spec again until the IESG approves it. it changed just yesterday

<DanC_lap> ... and the IESG is all but decided.

<Chris> RF: Once exists it will be approved

<DanC_lap> timbl, do you want the action on this?

<DanC_lap> that is...

<Chris> all URIs are IRIs, so there is only one identifier space

<DanC_lap> ACTION RF: notify the TAG when IESG has decided on IRI spec and suggest answers to timbl's questions


<DanC_lap> swapping in

<DanC_lap> reviewing Action CL: Write up a summary of the resolution.

<DanC_lap> CL: I've been hesitant to draft that since the relevant terminology in webarch was changing

<Chris> but now its stable

<Chris> 'secondary resource' and so on

<Chris> So I can do this, eta one week

<DanC_lap> ACTION CL: Write up a summary of the resolution. on fragmentInXML-28 continues.



<DanC_lap> reviewing ACTION Stuart revise finding

<DanC_lap> ^30 Nov summary of feedback

<DanC_lap> ACTION Stuart: revise finding on metadataInURI-31

<DanC_lap> reviewing PC's action to find out about DO's action

<DanC_lap> DC suggests withdraw

<DanC_lap> action PC WITHDRAWN.

<DanC_lap> SW: ETA xmas

<DanC_lap> SW: I'm willing to work on this until it's finished, regardless of my term

<DanC_lap> ----

<DanC_lap> break 'till 10:50

<Chris> I have just updated to take into account the xml:id last call

<Norm> Ugh. Chris did you send the HTML to Ian?

<DanC_lap> ---- resuming from break


<DanC_lap> reviewing ACTION2003-01-12

<DanC_lap> reviewing ACTION2003-01-12 DC Propose example of a site description.

<DanC_lap> PC finds "Action TB: Beef up use cases in draft finding."

<DanC_lap> CL: people use "web site" in 2 senses...

<Chris> scribe: Chris

<Chris> NW: confused by what chris said, didn't seem to be about sitedata 36

<Chris> DC: Its derived from robots.txt and p3p and things that saw of parts of the namespace

<Stuart> little wormholes in URI space

<Chris> DC: TBray wanted to have a doc that said 'this is a website' and I saifd 'no, its a website description' hence my action

<Chris> NW: Interested to see a finding in this area

<Chris> PC: Should we ask TBray about this?

<DanC_lap> DC: does the XQuery spec specify how to take the FO namespace URI and a name like concat and make a URI out of it?

<DanC_lap> PC: no

<DanC_lap> DC: webarch says you MUST

<DanC_lap> NDW: I have a proposal that I haven't yet made... to add fragids

<DanC_lap> PC: let's add this to our todo list, Norm. IR1 thingy.

<Chris> Hi David

<Chris> We are meeting in a different room this afternoon

<DanC_lap> David, 346 is the room for after lunch.

<Chris> joining us for lunch?

<DanC_lap> (a room number wasn't sufficient for me; I wandered around the building for 10 minutes before somebody held my hand...)


<DanC_lap> in basel ( we made a nearby decision, but not one to close this issue

<DanC_lap> PC: is this referenced in webarch?

<DanC_lap> DC: yes, in 4.5.2

<Chris> ----

<Chris> # xlinkScope-23 : What is the scope of using XLink?

<Chris> NW: Propose to wait for XLink 1.1 to see what happens

<Chris> SKW: Waiting for Liam to cause task force to meet

<DanC_lap> task force charter/genesis...

<Chris> first real message


<DanC_lap> DC: no duration. not optimal.

<DanC_lap> (also no public accountability)

<Chris> i agree, it needs to have an actual charter, milestones and deliverables

<Chris> To quote Ian Hikson "I don't really have a good solution though, not even for this very small

<Chris> problem set ("identify links and classify them as either hyperlinks or

<Chris> source links, without using external files, and without making it a pain

<Chris> to use for authors"). D'oh."

<Stuart> Bye


<noah> scribenick: Roy

<roy_scribe> scribenick: roy_scribe



<roy_scribe> Dave Orchard in attendance

<roy_scribe> PC chair for this afternoon

<roy_scribe> PC: I saw DO's presentation at the conference, a high-level summary -- shall we go through it?

<roy_scribe> DO's slides are not on-line

<roy_scribe> PC: DO has 45 minutes

<roy_scribe> PC: to present

<DanC_lap> Updated rough draft finding on extensibility and versioning for F2F

<DanC_lap> DC: I like the producer/consumer diagram. I wonder why 3 arcs and not 2/4

<DanC_lap> +1 discussion of substitution rules. I don't care for "ignore" terminology

<DanC_lap> nice diagram:

<DanC_lap> hmm... there's a question of _whether_ to use a schema language, not just which one, yes?

<noah> I think forward or backward compatibility is presented as much too much of a boolean relation. This was raised by me at Cannes last year. Even as an early version of an applications, there are shades of grey regarding the ways in which I will or won't process content that in some sense I don't fully understand.

<noah> I'm not as happy as Dan with the substitution formulation, though I agree that "ignore" is much too simplistic. There are ways I can process various newer forms without "Transforming" to an older form. For example, I can check a digital signature on the whole thing. I can use default rules for printing our outputting, etc. None of this involves a transform to a legal V1 form.

<DanC_lap> "Others substitution mechanisms exist, such as the fallback model in XSLT." is news to me. a specific section link into the XSLT spec would be nice

<paulc> Plan for issue 41:

<DanC_lap> while there are various ways documents can produced/consumed, but the web architecture has one main one, I think.

<paulc> Aug F2F discussion of issue 41:

<paulc> Oct F2F discussion of issue 41:

<DanC_lap> (checking to see if "xml 1.1 is not a compatible change" is noted in the Nov 2004 draft...)

<DanC_lap> yup... "A good example of an incompatible changed identified as a minor change is XML 1.1."

<DanC_lap> a citation link would be nice.

<timbl> XML1.1 is back but nor forwards compatible with 1.0, I assume

<timbl> Oh, no ... not compatible, when you include the <?xml ele

<DanC_lap> yes, I don't know why "incompatible" rather than "not forward compatible" was used

<DanC_lap> (I have an action from another forum to work on a persistence ontology... quite relevant to "version identification" slide)

<DanC_lap> (work in progress: )

<timbl> Eg the "Decision" on this slide connects to the transformation rules on anotehr slide to give f/b compatability results.

<timbl> UBM the example for a change every time anything changes.

<paulc> QA Spec Guidelines interaction with Issue 41:

<DanC_lap> "for each compatible version" -- forward or backward? (seems odd to introduce the fwd/back terminology and then not use it)

<DanC_lap> hmm... less fuzzy examples might be better, yes.

<timbl> Universal Business Language

<DanC_lap> UBL

<DanC_lap> DO: I sent a comment on UBL asking for [something]

<DanC_lap> (I wonder what became of that comment; I gather UBL is done-and-dusted)

<DanC_lap> DO: UBL don't intend to support distributed extensibility

<roy_scribe> timbl: what happens when entire namespace changes is that people begin programming to specific exceptions (i.e., if the parts I use have not changed, just internally ignore the namespace) -- that has a negative effect on third-party processing

<DanC_lap> NM: I'd like to discuss this at length; going over examples like UBL might be as important as the solution

<DanC_lap> ... or solutions

<timbl> timbl: What happens when UBL comes out with a different version is that the application engineers and lawyers look at the specs and contracts and decide whether one can for them be tretawed like the other.

<DanC_lap> "this is the most common" ... hmm...

<DanC_lap> NM: are people happy with the ns2 approach? DO: no, prolly not

<DanC_lap> did I miss a slide about "or use a different schema language"?

<DanC_lap> or "don't use a schema language"?

<DanC_lap> "swap trick" .. I don't grok. would have liked a slide on thqat

<DanC_lap> re slide "CVI Strategy #3..."

<roy_scribe> slide: Extension Element

<roy_scribe> slide: Schema V2

<DanC_lap> (noodling on a set of slides on how RDF addresses these issues: sacrifices handy XML syntax for stuff like order and containership; establishes the "erasure" substituion rule...)

<roy_scribe> NM: have concerns about focus on existing Schema limitations, rather than on the way forward on general issues

<DanC_lap> ("the current schema language" bugs me. Relax-NG is current. RDF is a W3C REC and addresses many of these issues.)

<roy_scribe> slide: #5 Incompatibe Extensions

<DanC_lap> TBL relates "#5..." slide to issue xmlFunctions-NN

<DanC_lap> xmlfunctions-34

<DanC_lap> xmlFunctions-34

<timbl> The RSS problem of which David speaks in my view follows from defining processing as oppossed to meaning

<DanC_lap> yes, but defining meaning is only a solution if it answers the processing questions, right, timbl?

<timbl> Yes, which is does in this case.

<DanC_lap> DO: I didn't get around to elaborating on RelaxNG and OWL/RDF for these slides, but I wrote a blog entry

<DanC_lap> PC: the "versioning activities" list is missing QA WG work

<roy_scribe> DO: plan to do more reference to the QA work in the finding

<roy_scribe> PC: what QA is proposing is that it would be better if the SOAP spec laid out the specific extensibility points in one section

<roy_scribe> DO: end of presentation .... questions?

<paulc> Plan for issue 41:

<paulc> Which of these items are done?

<Zakim> tim2, you wanted to say: Missing concept -- damage involved. Compat can be quntitative, eg when middle name is removed?

<Zakim> timbl, you wanted to ask for a more formal treatment in some places. For example, operation of interpreting a doc in language x as if it were in namespace y. XML version numbers

<paulc> I did not ack him twice - I think someone else did.

<paulc> IRC indicates that timbl himself did the "ack tim"

<DanC_lap> ah

<roy_scribe> timbl: the may-ignore extensions are not really ignored -- they are just not processed (kept in some reserve, perhaps)

<roy_scribe> timbl: you could write down some math that reflect the extension rules using substitutions

<roy_scribe> timbl: [discussion of other ways to describe forward and backward compatibilty by phrasing it in terms of substution rules]

<roy_scribe> DC: there are no documents that are both xml 1.0 and 1.1

<roy_scribe> DC: because the version is labeled with the document [??]

<Zakim> noah, you wanted to make a number of comments queued up on Dave's presentation

<roy_scribe> noah: there are many shades of gray.

<timbl> XML 1.1 specifies a language we can call XMLP1.1 whcih is the set of documents an XML 1.1 processor is supposed tro be able to receive, and is union of XML1.0 and XML1.1.

<timbl> XML1.0 and XML1.1 are incompatable.

<timbl> XMLP1.1 is backward compatible with XMLp1.0 = XML1.0

<roy_scribe> noah: my view is that rather than saying there is a binary backwards and forwards-compatibility, they should state the ways in which they will process content

<Zakim> DanC_lap, you wanted to ask if there are any non-hypothetical examples of "must understand" mechanisms (does new HTTP verbs count? non-WF XML?) and to say I like do's diagram, and

<roy_scribe> noah: there is a bit of a trap in treating it as a binary condition, maybe looking at it as shades of gray would free up the text

<noah> suggest s/treating it/treating compatibility (e.g. forward compatibility or backward compatibility)/

<roy_scribe> DC: I like the diagram -- it oversimplifies in ways that are consistent with web architecture

<roy_scribe> PC: had some high-level questions about the docs sent in e-mail on 26 Nov


<roy_scribe> PC: missing response to the work plan... how much is done?

<paulc> Plan for issue 41:

<roy_scribe> DO: I have not done the protocol extensibility and service compatibility (from the work plan message)

<paulc> Items on the plan not done:

<paulc> - add protocol extensibility,

<paulc> - Add material on issue about service compatibility

<roy_scribe> DO: looking at what can be done to describe compatible/incompatible flags to operation extensions

<DanC_lap> (glad to know DO is noodling on all this stuff, and that my impression that XML Schema problems was the whole story was mistaken)

<timbl> Compatible services: ?

<paulc> Only first item in Part 2 was done:

<paulc> - insert original xml schema material

<roy_scribe> noah: first, I think there is a lot of good work here... trying to figure out what is appropriate for a TAG finding

<roy_scribe> noah: there are a set of idioms ... would be stronger if the finding strarted by emphasizing the principle

<roy_scribe> noah: up front


<paulc> Above link is member-only.

<DanC_lap> (bummer V-F1, VF-2 is member-only; pls send to www-tag, noah)

<roy_scribe> noah: look for the principles, list the use cases, and treat the issues at a high level before getting into the details of idioms

<Zakim> noah, you wanted to talk about more of the things I had queued up during dave's talk and to mention input from XML Schema WG

<Zakim> DanC3, you wanted to comment on the barrier to entry to the XML Schema WG

<roy_scribe> noah: would like DO to enter the schema group and see the (non-public) scenarios


<roy_scribe> DC: sympathetic to barrrier to entry in schema WG -- it is natural effect from a wg with 7 years of history

<noah> not quite: I've suggested we are doing a lot of work and I think we'd like to find a way to make it convenient for Dave and other TAG members to have an effective liaison with the Schema WG with respect to the versioning issue in particular

<roy_scribe> DC: it needs to be made public

<Zakim> DanC_lap, you wanted to ask if there are any non-hypothetical examples of "must understand" mechanisms (does new HTTP verbs count? non-WF XML?)

<roy_scribe> DC: are there any examples to provide that show must-understand in practice?

<DanC_lap> NM: SOAP

<roy_scribe> Roy: is that SOAP in practice, or just theory?

<roy_scribe> DO: bulk of use is not in distributed extensibility (planning for other folks extensions)

<roy_scribe> DO: version identifiers often mean capability rather than format of this message

<roy_scribe> NM: XML 1.1 is a countter-example (very rare)

<roy_scribe> NM: flexibility is often in conflict with interoperability

<DanC_lap> RF: yes, HTTP spec says new verbs are "must understand". except for proxies

<DanC_lap> DO had a sort of "good question" look. timbl said yes.

<roy_scribe> NM: M-PUT extensibility mechanism is an example, but not widely deployed

<roy_scribe> PC: we extracted some text for webarch -- does the updated finding mean that we should change the text in webarch?

<roy_scribe> DO: no, it is augmentation so far

<roy_scribe> PC: I think NM was saying that the material in webarch was not high-level enough?

<roy_scribe> NM: I think there are lots of principles between the levels of webarch and the current content of the draft finding

<roy_scribe> DO: some are implicit

<roy_scribe> NM: they should be explicit -- they are the main event when it comes to teaching others how to do extensibility and versioning

<paulc> Norm: are you still there?

<roy_scribe> DO: trade-off of breadth vers brevity

<Zakim> DanC2, you wanted to noodle on writing the E+V book breadth-first or depth first, and to lean toward "write about what you know"

<roy_scribe> ACTION NM: to work with DO to come up with improved principles and background assumptions that motivate versioning finding

<roy_scribe> DC: glad to see chapter 2, see noah asking for chapter 1, but I'd like to see more discussion of the rest of the problem space beyond issues with schema 1

<DanC_lap> ACTION DC: review blog entry on RDF versioning [pointer?]

<roy_scribe> ACTION noah: work with DO to come up with improved principles and background assumptions that motivate versioning finding

<roy_scribe> DC: title is much broader than the topics being discussed in the finding -- what about RELAX NG, OWL/RDF, ...

<roy_scribe> timbl: can we change the title of the first draft to better reflect the content?

<noah> Noah: suggest that if we do have a W3C XML Schema-specific 2nd part, then that might more appropriately be owned by the Schema WG (though I would not want to lose Dave's work and would want him to make a major contribution)

<roy_scribe> PC: xml-binary is an example where we wrote a problem statement and then asked others to form a group -- we could do the same here

<roy_scribe> timbl: TAG work has been half vertical and half horizontal (finding depth and webarch breadth)

<roy_scribe> NM: the schema WG work and TAG's work (through DO) seem to be taking place on different planets, which is unhealthy

<Zakim> timbl, you wanted to say there is some connection you could write up between message format extension and protocol extension.

<Zakim> noah, you wanted to ask about review process for what Dave has written

<roy_scribe> DO: there are limitations to what a single volunteer has time to cover

<roy_scribe> NM: is now the time to focus on this (process wise)?

<Norm> I'm here

<roy_scribe> DO: TAG in general has not said what the next step should be (i.e., indicated approval of the outline so far)

<roy_scribe> NM: how about placing that on the agenda for a specific meeting in January?

<DanC_lap> +1 the ball is with the readers, not the writers, at the point

<Norm> I think collecting some solid review would be good

<roy_scribe> DC: wants this stuff to be public first

<roy_scribe> NM: will need to check for permission first (no objections likely)

<roy_scribe> PC: why not just pass the work?

<roy_scribe> DC: we are talking about joint work because we (Dave, Norm) have invested a lot of work and have (so far) been unable to interface with Schema due to legacy barrier

<roy_scribe> DC: has Schema done a public working draft?

<roy_scribe> DO: fails to mention widcarding stuff

<paulc> What we have to decide:

<Zakim> timbl, you wanted to say there is some connection you could write up between message format extension and protocol extension.

<paulc> a) when we will review XV Part 1 and when will we discuss the feedback

<paulc> b) what we need to finish today

<Norm> Still on break?

<roy_scribe> yes

<Norm> thx

<roy_scribe> back from break, returning to discussion on extensibility and version

<roy_scribe> ing

<Chris> Daves slides


<roy_scribe> Norm: I'd like to see feedback from the TAG first

<roy_scribe> PC: happy to read it on the flight back home

<DanC_lap> ACTION PC, DC: review nov part 1, 2 of E+V draft finding

<DanC_lap> ... for 10 Jan

<roy_scribe> ACTION PC: to review parts 1 and 2 of extensibility and versioning editorial draft finding prior to discussion for 10 Jan. ACTION DC: paulc to review parts 1 and 2 of extensibility and versioning editorial draft finding prior to discussion for 10 Jan

<roy_scribe> PC: regarding tech plenary, our discussion earlier suggested that a session on this topic would be good

<Chris> take two: DO's slides

<Chris> This is the presentation that Dave Orchard gave at todays TAG meeting.


<roy_scribe> ACTION PC: paulc to inform QA and Schema WGs of the new version of the e&v draft

<noah> ACTION NM: to explore means of getting current and future Schema WG work on versioning into public spaces

<DanC_lap> (I gather a certain amount of duplication is inevitable, but yes, let's mitigate it to some extent)

<noah> Agreed...just some discomfort with the spin that as long as there are no patent issues, anything goes

<timbl> Danc, DaveO may have "substitution groups" mentioned in the existing part2.

<Zakim> noah, you wanted to say we should still watch out for duplicating requirements effort on XSD-specific requirements

<timbl> So he may have covered this method of doing extensions.

<DanC_lap> 3.3 Substitution Groups

Type-based solutions without <extension> element

<DanC_lap> (did you just mean to clear the agenda?)

<DanC_lap> (the meeting gets to timbls' agenda request...)

<Zakim> DanC_lap, you wanted to offer some work on CDF and XML Schema mixing

<roy_scribe> DC: was trying to see if composition of data formats is possible using schema

<Norm> What file are we looking at?


<Chris> mathml-renamed.xsd

<Norm> ty

<Chris> np

<roy_scribe> so is the scribe

<DanC_lap> (yes, Dave, I think it gets down to fine details about when "compatible" assumes access to a schema)


<roy_scribe> PC: let's return to open issues


<roy_scribe> PC: was pointed out that the document is not yet polished

<roy_scribe> DC: start with Stuart's null hypothesis: if WSDL has done something and is happy, do we need any further action?

<Chris> This was the () considered harmful in fragments.....

<roy_scribe> DO: Roy has an action URIGoodPractice-40

<DanC_lap> (I and a few others have been discussing good URI construction practice in a wiki. GoodURIs)

<roy_scribe> DO: so, this issue is done unless it needs to be revisited after URIGoodPractice-40

<Zakim> Chris, you wanted to talk about what HTML did

<Zakim> noah, you wanted to say that schema is chugging along too, if that matters

<noah> FYI: July 2004 Working Draft of XML Schema:Component Designators is at

<roy_scribe> Roy: when names are being created by a description language (like WSDL), the distinction between using fragments versus using URIs is not important any more because it has been assumed that the document has already been retrieved (and, hence, isn't going to suffer form the huge flat namespace)

<Norm> ping?

<DanC_lap> (yeah! the relevant WGs are talking about it already!)

<paulc> SW use of SCUDs:


<DanC_lap> (yay! dan't can't spell yay!)

<DanC_lap> RF's offer to write on 40 on Jan stands, but there's some questions about the relationship to 37...

<DanC_lap> TBL: let's change 37 to get rid of the ()'s [?]

<DanC_lap> DO: let's start a finding on 40 that argues against ()s

<DanC_lap> CL: ISO MPEG is building a thing of indexing into video based on XPointer-like syntax, using ()s

<Chris> WebCGM also uses nested parens in fragments

<DanC_lap> RF: meanwhile, RFC3023 is headed toward endorsing XPointer ()s for all +xml media types.

<DanC_lap> TBL: I don't follow the argument that LR syntax in fragids is bad


<Chris> "Pictures and objects (application structures) within a WebCGM are addressed using the mechanism of the URI fragment. These WebCGM rules are derived from and are consistent with the Web protocols defined in RFC-2396."

<Chris> (BNF follows)

<Chris> WebCGM 1.0 Second Release

<Chris> W3C Recommendation, 17 December 2001

<DanC_lap> RF: URIs ala lsdjflkj#abc(../foo) get parsed wrong; consumers treat / as part of the path

<DanC_lap> some consumers


<roy_scribe> DerivedResources-43

<roy_scribe> DO: can't remember which of XInclude's use of fragments was the issue

<roy_scribe> DO: brought this up because there was no normative material explaining why what they were doing was unsound

<timbl> +1

<noah> FWIW, The AWWW PR says:

<roy_scribe> NW: as a result of other feedback, XInclude changed its use of fragments and that we may not need to do anything further

<noah> ...never mind...

<noah> Found it. AWWW says "The Internet Media Type defines the syntax and semantics of the fragment identifier (introduced in Fragment Identifiers (§2.6)), if any, that may be used in conjunction with a representation."

<Zakim> timbl, you wanted to say that the issue that, as he recalls, was about the way XInclude seemed to be abusing fragids, and that he agreed, and that XInclude was changed.

<Zakim> DanC_lap, you wanted to ask timbl to say, kinda slowly, why he thinks the status quo is correct, and maybe we could RESOLVE that that's the answer to this issue

<roy_scribe> DC: 1) if the WG was persuaded to change things, I don't mind writing down the argument

<roy_scribe> DC: 2) if it was just a non-persuaded process decision, then there's no point in going there

<DanC_lap> I think a TAG decision is worthwhile here.

<roy_scribe> example: href="...chap3#xpointer(h2[3])

<roy_scribe> example: 200 response from action says the representation is "text/plain"

<noah> Doesn't it matter if it's href="http://chap3#xpointer(h2[3])

<roy_scribe> Chris; provides example of math+xml and the desire to identify an SVG view of part of the rendered math

<DanC_lap> DC asks CL to package that mathml/SVG example up, mail it to the CDF WG and ask them if they're going to solve it or not

<DanC_lap> DC also pointed out that if the mathml/SVG example had 200 content-type: mathml, then the mathml media type spec would have to specify how the XSLt transformation to SVG interacts with fragid syntax

<roy_scribe> timbl: use of a URI in a retrieval action has a single meaning that cannot be overridden by something like XInclude just because it appears as an identifier during an inclusion action

<DanC_lap> ACTION CL: to package that mathml/SVG example up, mail it to the CDF WG and ask them if they're going to solve it or not

Thanks to the host, adjournment

<DanC_lap> next agendum


<paulc> Paul suggests that meeting record makes clear what issues we did not do at this meeting.

<DanC_lap> RESOLVED to thank the host! thanks, Amy!

<paulc> TAG thanks Amy and W3C for hosting our meeting.

Changes, Acknowledgements

Minutes formatted by David Booth's scribe.perl 1.81 (CVS log)

$Log: 29-30-tag.html,v $
Revision 1.19  2004/12/09 18:44:46  connolly
moved photo/participants up

Revision 1.18  2004/12/09 18:42:56  connolly
more actions/agenda stuff

Revision 1.17  2004/12/09 18:20:17  connolly
condensed action summary
(items after siteData-36 still need review of actions)

Revision 1.16  2004/12/09 17:56:50  connolly
found more actions

Revision 1.15  2004/12/09 17:51:23  connolly
agenda/summary includes a decision on profile29
found some more actions

Revision 1.14  2004/12/09 17:39:24  connolly
refined proposed rec comment items
promoted rec planning to an agendum
found action re 39
fixed a few in-your-face URIs

Revision 1.13  2004/12/09 17:13:19  connolly
integrated action summary into agenda

Revision 1.12  2004/12/09 16:13:42  connolly
reviewing action summary; connecting them to agenda

Revision 1.11  2004/12/09 15:53:09  connolly
moved agenda stuff

Revision 1.10  2004/12/09 15:49:26  connolly
integrating 2 IRC sections into one set of minutes

Revision 1.9  2004/12/09 15:40:24  connolly
moved agenda topics for from day 1 IRC section to top

Revision 1.8  2004/12/09 15:37:59  connolly
removed irc-log versions of topics I did manage to summarize

Revision 1.7  2004/12/09 15:34:07  connolly
pasted in IRC logs processed by the dbooth scribe thingy

Revision 1.6  2004/12/07 22:06:48  connolly
"future ..." section done-ish

Revision 1.5  2004/12/07 21:55:58  connolly
nav tweaks

Revision 1.4  2004/12/05 22:40:28  connolly
- summarized monday admin
- working on future directions