TAG f2f, Edinburgh

22 Sep 2005

See also: IRC log


Tim Berners-Lee, Dan Connolly, Roy Fielding, Noah Mendelsohn, David Orchard, Vincent Quint, Henry S. Thompson, Norm Walsh
Ed Rice
Vincent Quint
Henry S. Thompson, Noah Mendelsohn, David Orchard



<scribe> Scribe: Henry S Thompson

XML Versioning

VQ: Resuming discussion from yesterday -- we started from Dave Orchard's draft, shifted to building a diagram based on Noah's comments on that draft, synthesised on the whiteboard by DanC and others. See whiteboard photos.

Discussion of how to add versioning to this diagram

TBL: Producers of instances of serialisations _commit_ to the _meaning_ of those serialisation
... wrt the language of the serialisation
... A backward-compatible language means that the serialization is also a member of that language

Debate ensues about the relationship between 'serialization' and 'instance' and their relationship with languages

NM: producers produce instances wrt a language, consumers consume wrt (possibly different) language

HST thinks this means it's a 'production' or a 'consumption' which has a language property

NM: Producers produce instances, I don't think we have to say what language they have in view, good practice may be to indicate the language, but not required. . .
... E.g. I wrote some VCard stuff, with a particular understanding of what VCard constraints are at that time
... Then Dave processes it, based on expectations from a range of sources, wrt some, possibly different, understanding of what VCard constraints and meaning are

DC: We need to have some point at which we say how the thing gets a meaning

HST: Suggested accommodating all this by shifting to 1 Production of an instance, multiple Consumptions of an instance, Productions and Consumptions have a Language their _producer_ resp. _consumer_ had in view to constrain/determine its syntax and semantics

NM: Instances do not necessarily indicate their own language

TBL: WebArch says they should

DanC: There's no difference left between Instance and Serialization, let's get rid of it

TBL, NM: Agreed, settle on Serialization

HST: Nervous, but go ahead

DanC: Working on example now

TBL, HST: Then add something such as _intent_ from Production to Information and _impact_ from Consumption

scribe: to Information

DC: In the example we have two Consumptions wrt different Languages of the same Serialization/Instance

TBL: Fred (producer) only commited to I1 (interpretation wrt POL1 (PurchaseOrderLanguage v.1)), Barney (consumer) consumes wrt POL2, now we can talk about backward compatibility

DC: So I2 (interp wrt POL2) implies I1 when POL2 is backwards compatible with POL1

NM: Uncomfortable with this, defining e.g. backward compatibility too soon

DC: miscommunication is reading and writing in different languages

NM: Our formal use of language so far can't say that, because language is just a set of strings

TBL: Important that Fred not saying anything about middle name, but Barney reads that wrt a different interpretation which makes him conclude that there *is* no middle name, that's not backward compatibility

<noah> What I tried to say is: we've "hijacked" the term "language" to be a set of strings, along with their correct interpretations. That's OK, but it's also interesting to talk about the set of strings. Why? Because then I can talk about the strings that are "accidentally" in two languages, and thus subject to undetected misinterpretation.

TBL: HTML2/4 example

NM: People want to build bounded risk incompatibility

DO: Syncing on Production and Consumption
... What we don't have yet is the whole space of Constraints -- syntactic, semantic, textual

TBL: syntactic constraints are on the board at the moment as Syntax

DO: Semantic constraints are just as important for compatibility
... Languages have Constraints, subcategorized as Syntax or Semantics

NW: Not the way I've used backwards compatibility -- PO1 grammar, first and last, PO2 adds lineage to distinguish senior from junior, this is backwards compatible because all the old instances are valid

DC: Do they mean the same thing

NW: Yes

DC, others: Then you're cool

TBL: This is precisely where this often catches people

HST: NM was right to complain as more relations were added to Language -- Languages are *just* a set of strings, if we were being careful we would distinguish between that and a DefinedLanguage or an InterpretedLanguage, which includes constraints and interpretation rules
... But we could elide this distinction

TBL, others: Lets use Language for the latter and StringSet for the former

RF: We're getting too far from anything anyone will understand, stick to terms from XML

HST: Can we agree to restrict ourselves to XML languages?

Others: No

HST: How about Document (for Serialization) then?

DO: No, I want to talk about parts of things, not just whole documents

DC: Expression?

DO: I wanted Component

NW: I'm happy with Document, I can use it for parts as well as the whole

NM: Then we add a para saying don't assume this means the whole thing

DC: Back to HTML2 vs. HTML4

TBL: Take <SPAN STYLE='color: green>...</SPAN> in a document produced by Fred in language HTML4
... with intent I4,

<noah> scribe: noah

DC: What's relationship between i4 and i2:

TBL: I4 > I2

DC: I4 includes I2

TBL: I2 follows from I4

NW: Bothered by the example

TBL: I call this weakly forwards compatible

NM: What do you mean follows from? One guy knows it's green, one doesn't.

DC: right, using implication for this doesn't fit quite right.

TBL: Note that there are no syntactic constraints...it's just that H2 says the interpretation of style="color:green" is no impact
... one definition of compatibility is: anything you miss doesn't matter.

<scribe> scribe: ht

DC: WebArch comes in to play when we look at specification documents

DO: Kind of Constraint

DC: ref. rdfURIMeaning-39
... Schema documents can be compatible with one another in various way

TBL: [W3C XML] Schema documents contain semantic info?

HST: XML Schema language provides a place for semantic assertions to be packaged up with the syntax which is its primary focus

NM: That gets used, but at least as often the semantics is elsewhere

DC: Want to encourage this, it's closer to the self-describing 'follow-your-nose' goal of the Web

NW: Consider the case where I produce some HTML2 and include, because I can, the span tag for my own purposes, then later HTML4 overtakes me

DC: Your bad

HST: Would like to come back to the fact that for XML documents, syntax and semantics are (almost always) compositional, and that gives us a lot of leverage

TBL: Produces graphic of the example: http://www.w3.org/2001/tag/2005/09/22-diagram1.png

diagram of one document in two languages

<timbl> Note re diagram above, the table in it was suppose to read something like:

<timbl> r1 r2 back-compatible = weakly compatible subset

<timbl> (superset?)

postscript: see po-situation.n3, Makefile

language/document/instance diagram, omnigraffle source, whiteboard photos

postscript: UML diagram of language/version terms
source as saved from Violet
derived OWL/RDF via grokVioletUML.xsl (see Makefile)

[coffee break]

<dorchard> scribe: dorchard

<scribe> ACTION: Dave O to update finding with ext/vers [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action01]


ht: everything on namespace and grddl file is sensible but without language ontology and it's relationship to namespaces, nervous to issue ns-8.

norm: don't think that follows, ns can say "here's some stuff".

<Zakim> timbl, you wanted to say that the question of languages for namespace documents esp in the machine-proc area is very open area of development, and we should understand that currently

timbl: owl and owlk are useful, lots of innovation happening.
... should recommend owl. ?scribe didn't catch all

dave: don't we say human readable in web arch?

ht: should be agnostic.

<DanC_lap> (double-checking, yes, we did say that, dave... " The owner of an XML namespace name SHOULD make available material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace vocabulary")

timbl: if using owl, then provide owl.

ht: for argument sake, should put xml schema because it's widely adopted, well understood and closed world.

<Zakim> noah, you wanted to say why can't we write a short finding that's quite open in what a namespace doc can say?

<Zakim> ht, you wanted to object to privileging any particular description

noah: minting new formats for ns documents is somewhat similar to minting new uri schemes.
... if owl on the merits won..

<Zakim> DanC_lap, you wanted to ask some mechanical questions about namespace document vocabulary... rddl:purpose and rddl:nature relationship to rdf:type and rdf properties and to say I'm

ht: for stylesheet, if view purchase order then purpose is view on mobile phone,
... why purpose AND nature.
... schema is bad example because they are the same, validation.
... could have nature is stylesheet, purpose could be html browser view.

<ht> <rddl:resource xlink:role="...#stylesheet" xlink:arcrole="...#mobileview" xlink:href="...mobile.css"/>

<ht> DC: What's the RDF for this. . .

muchos discussion on rddl:purpose, nature, etc.

norm: rddl:purpose is a subtype of rdf:property

ht: people won't be looking at this for what they need, if they don't know the purpose then they are toast.

<povocab> rddllibstylesheet <mobile.css>; mobileView <mobile.css>; rddlib:stylesheet <desktop.oss>; desktopview <desktop.css>;

norm: validation <x.xsd>; validation <x.rng>; rddlib:xsd <x.xsd>; rddlib:relaxng <x.rng>;

ht: original design was right. In the absence of multiple resources of same nature, you can infer purpose from the nature.
... what's missing from rddl is the tabulation is the default mapping
... better example
... might have 2 resources of nature html, one is purpose normative reference the other is non-normative reference.

norm: could have normative reference to pdf

<timbl> Tim: This is clearly a good example of the translation as a predicate

henry: found a nature not in table

dan: go looking for nature.

<timbl> DanC: In the translation, i could look up the default purpose for a given nature by looking the nature up at its URL.

noah: what about installation instructions? If at that granularity, then whats the purpose? the range is so wide..

<timbl> Tim: So we need a relationship between a nature and its default purpose?

norm: need to normative to one and non-normative to another, can't just say both references.

dan: If a link has been made, then there is a relationship

timbl: you are making a change in rddl spec, to if there is nothing specified then there is nothing specified, not infer as currently says.
... spec says you can infer on absence of arcrole.

<timbl> currently

<timbl> and danc suggests a change to the spec such that inference is not possible explicitly from the absence of an arcrole

<povocab> rddl:ref <spec><tut>; rddl:normativeRef <spec>; rddl:informativeRef <tut>; spec> nature HTML. <tut> nature HTML.

do: what does this mean?

noah: Noah invents "better" rddl for his namespace, this works IF noah also creates a GRDDL xform that will also produce above statements.

<DanC_lap> ACTION: DanC to ask for "default nature" to be changed to "implicit nature" in RDDL spec [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action02]

<DanC_lap> DanC: draft a section on using XHTML 1.x (not RDDL) with GRDDL and relax-ng[CONTINUES]

<DanC_lap> NDW: follow-up on namespaceDocument-8, based on DanC's vanilla XHTML example [CONTINUES]

<DanC_lap> (my understanding of the namespaceState-51 issue is that it depends pretty heavily on versioning, so I'm surprised it's slated for closure today. taking a look at http://www.w3.org/2001/tag/doc/namespaceState.html )

<DanC_lap> tim, got a suggestion for "commitment" in the following?

<DanC_lap> { ?WHO is :producer of [ :intent ?I ] } => { ?WHO :commitment ?I }.

Strategic Priorities

timbl: should each do writing chunks

danc: go around the room and see what each people think is important
... for me, versioning including namespaces, rdf meaning, component refs

timbl: self-describing documents.
... can imagine with or without versioning.

roy: nothing in specific

norm: like versioning - it's a cluster. Also media type and this may be part of self-describing

dave: I like the versioning stuff; I think that relates to componentRefs
...I'm quite interested in questions of state that we haven't worked on very much
...I think state is underrepresented/omnipresent part of webarch
...I still feel that we're missing something in getting people to use URIs where they could
...GRID; P2P; etc.
We need to focus on realistic aspects of what people are doing about state and how to expand the use of URIs in new technologies

vincent: namespaces including versioning, namespace document, abstract comp refs, namespace state.

timbl: semantic web documents and pairing with somebody (norm and Noah express interest)

<timbl> The Nadia and Dirk my first semantic web book

HT: doing a careful ontology of the xml space and moving downwards to xml documents and infosets
... would be good to have a way of describing languages and relating them.

<DanC_lap> (happiness... a while ago, I tried to write http://www.w3.org/2000/10/swap/util/changePolicy.n3 using terminology from our versioning draft finding and I got stuck. Using the terms from http://www.w3.org/2001/tag/2005/09/22-diagram1.png , I'm unstuck.)

ht: semantic web isn't archaeology so constraints aren't clear.

noah: 3 piles. 1) Web exists.
... 2) web just progressing nicely isn't necessarily the future, ie multimedia
... sometimes when you have a big goal, and you need big writing.
... now we have to do stepwise work.
... willing to take on faith that self-describing is important.
... suggesting that be separate from ext.
... maybe we should talk about web of applications.

<DanC_lap> (hmm... I think versioning is kinda boring if you don't connect languages to their specifications in the web. hmm.)

<Zakim> DanC_lap, you wanted to amend my "what I want to do" with authentication (which is a common case of state)

<Zakim> ht, you wanted to re-raise state/cookies/context/. . . and to mention persistence, diffidently

<DanC_lap> timbl: yes, let's keep an active thread on security, esp failures like phishing

danc: security..

ht: Cookies and state and sessions and the real world
...if you just read web arch, you'd find the use of cookies/state surprising.
...So, persistence: First with the XRI stuff, and then when I went to a workshop on Persistent Identifiers http://www.dcc.ac.uk/training/pi-2005/index run by the Digital Curation Centre, I see an awful lot of folks out there, some of whom are thoughtful and technically savvy, who just don't believe http: can do it for them
... then there was the observation at the Web Science workshop that there's no easy widely recognised way to say "that URI, at this particular time"
... So maybe we should do something about explaining how to get what these people want using http:/building on top of http:

RF: People just don't understand what names are, telling them again won't help

DO: Well, my company provides services based on stateful use of URIs which outperform RESTful alternatives

RF: In principle caching will always dominate any server-side speedup, and that's what REST buys you

DO: but that only works for cachable transactions, and lots of ours aren't

<Zakim> timbl, you wanted to discuss integrity vs lots of little bits

noah: henry made a good point, lots of people are doing this, either we say in more detail why they shouldn't or we should say what we learned.

<timbl> http://www.w3.org/Provider/Style/URI needs to be countered by info about how to use cookies, what information should be in a cookie.

timbl: what about client side state
... and ajax

<DanC_lap> (the best rule I know for what to put in the URI and what to put in the cookie is the 3rd grade grammar rule about "which" vs "that". restrictive clause stuff goes in the URI. non-restrictive clause stuff doesn't.)

much discussion about ajax, how it could/should use uris.

<timbl> Possible: Noah and Dave continue on versioning, Norm and Tim work on Sem Web Nadia & Dirk, DanC and Henry work on self-describing web

also, I'm partway through a nadia and dirk story for state.

HT: Core WG should publish an updated ontology for the infoset

HT: cmsmcq misses "element type" --- the fact that "element type" is no longer a defined term the community can use

timbl: write a whitepaper on phishing..

ht: here's why the arch is vulnerable, but also how fixing that would be throwing baby out with bathwater.

do: security is a spectrum.

<DanC_lap> (ok, I'll let the TAG know what comes from team project review of some security/UI stuff)

<DanC_lap> ACTION: DanC to derive RDF/RDFS/OWL version of terminology from whiteboard / http://www.w3.org/2001/tag/2005/09/22-diagram1.png [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action03]

<timbl> ACTION: Henry to make sure that what he is doing with ontology of XML infoset fits with what DanC is doing on ontology of Language etc [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action04]

<timbl> Transfer Versioning as action to DO and NM

<timbl> ACTION: DO and NM to continue and extrapolate the versioning work DO et al have been doing already, updating the terminology section. [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action05]

<timbl> ACTION: TBL and NW to write a draft of Nadia and Dirk first semantic web book [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action06]

<ht> scribe: ht


DO: Lots of WS-xxx (addressing, eventing, ...) we're using an XML structure, namely EPRs as identifiers, so we're outside WebArch
... TAG could ask "Why can't you use URIs instead?" or say "Don't do that" or even embrace and extend . .. .
... WS-Addressing is approaching/in/? CR, we're running out of time to push back if that's what we wanted to

<DanC_lap> Web Services Addressing 1.0 - Core

<DanC_lap> W3C Candidate Recommendation 17 August 2005

<DanC_lap> ws-addr

TBL: Dave Snelling from Tuesday left me thinking that many of the uses of EPRs could be reconstructed as URIs, but maybe not all

<DanC_lap> (so indeed, the TAG should have already given its technical input)

TBL: Perhaps we're confusing two things, a name and a bundle of answers to a set of questions
... One possibility is that the TAG try to tease these apart, and be clear about when you're doing what, so that you use the right tool for the job

<scribe> ACTION: VQ to write "Thank You" to Dave Berry <daveb@nesc.ac.uk>, David.Snelling@uk.fujitsu.com, with cc to Malcolm Atkinson <mpa@nesc.ac.uk> and David De Roure <dder@ecs.soton.ac.uk> [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action07]

NM: Some discussion of how WS-Addr got to CR while distancing itself from WebArch insofar as it does

RF: When people say "What we're thinking of is an entirely different architecture", I give up on detailed criticism and just wish they would call it "XML Services"

NM: Disk drive interrogation example -- message based, or couldn't a disk drive serve web pages
... GET for what GET is good for, more service-oriented messages for other things

RF: There's a lot of non-RESTful architecture out there, and that's just fine

NM: So should the Web stop with REST?

RF: No, absolutely not -- the Web information space is much more than the software of web clients and servers, whose effective interaction is what REST tries to explain/describe. Lots of other architectures can interact with the Web information space in other ways

<Zakim> DanC_lap, you wanted to ask timbl about "an epr could just be an rdf/owl bnode"

DC: EPR is a little description of properties and their values == RDF?

TBL: Yes, looks a lot like N3 with [] around it

DC: So should we ask WS-Addressing to do a model-theoretical semantics of EPR

<Roy> What is important to me in the Web Services design space is that, when services of any kind create information that becomes a resource, that the resource be assigned a URI and supplied to the service's client such that it builds on and improves the Web

<timbl> [ ref 3425; withRespectTo 1235421345; sentToBy ex:Joe; status 9]

HST,NM: OT discussion of formalizing XML Schema

<Roy> EPR := end point reference

TBL: EPR is not built to a requirements spec -- it will have the SOAP header problem, someone will say "here is a reference extension property which tells you how to decode the value of other properties", i.e. no guarantee of monotonicity or independence of interpretation

NM: Most uses are much more private than you're envisaging, the only person who interprets them is the person who mints them
... It has structure because I find that useful, that's all

TBL: Contract of opacity, then, right? Note URI you have a server and a client, but for EPRs they get minted, passed around, packaged and unpackaged, .. .

NM: Yes, packed in SOAP, but not quite opaque, because at reply time the responder has to crack it to find the address property of the ReplyTo EPR

<Zakim> DanC_lap, you wanted to say so supposed we accept that the time for technical input is closed; what can we do to help QA? what's the test experiment for an EPR? is there such a

HST: Well, not replying as Noah described would be an incorrect use

NM: Checking that what I said is in the spec. . ..

TBL: You could fail to unpack the EPR into the returning SOAP header as required. . .

NM: right

TBL: How do we demonstrate interop

NM: Transport independence, one dimension, how do I transport over SOAP, so expect a test case that if there are n properties with values in the reply epr, they have to come back as n attributes in the soap header

<Zakim> DanC_lap, you wanted to ask about the rot13 thing in such a test case

NM: I don't think so, the client's only responsibility is to echo everything but the address back

<Norm> So these really are just cookies?

TBL: Client has no obligation to interpret or process the EPR

DC: No way to say "Everyone who looks at this must ..."?

NM, TBL: No.

NM: So the fact that this is so private that there's no reason for WebArch to care

TBL: But if you hide a document behind one of these, it's usurping the role of a URI, but it's not "on the Web" anymore

<DanC_lap> (I now can't see what there is to do in this space. I'm OK to withdraw this issue)

<Zakim> ht, you wanted to ask TBL to elaborate

HST: How do you hide a document

TBL: Remember David Snelling's example of using an EPR in a client->server message to a generic URI to determine what you get back from your request. .

HST: That's a completely different kind of use than the scenario you and NM were just talking through

TBL: Yes, but nothing in WS-Addressing stops them doing that

VQ: Getting to consensus that there's nothing here to spend more time on

NM: I don't think I'm there yet

DC: I am happy with that, i.e. withdrawing the issue

<noah> FYI: here's the part of the WSA spec that I think more or less bears out what I said about refparms being echo'd in a reply, with the reply destination coming from the replyTo address: http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/#formreplymsg

DC: Not in order to withdraw the issue in DO's absence. . .

<noah> Here's the part of the WSA that says when sending such a thing over SOAP in particular, each ref Parm turns into a SOAP header: http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/#bindrefp

DC: So what problem have we identified

TBL: WSRF use of EPR to effectively identify a resource to be retrieved

NM: So we can say EPRs can be misused, but not WSA is broken
... When I summarized my limited understanding of the WSA design, I did not remember that that it does say that if you see [reference parameter] in an EPR that you don't understand you can ignore it
... That compromises my story that EPR content is largely opaque

<Zakim> DanC_lap, you wanted to ask if timbl's problem description is something we have consensus on; I'm somewhat sympathetic, but I'm not sure it identifies a problem with ws-a

DC: So are we agreed that this is bad

HST: Yes, with the above proviso, that WSA's use of EPR isn't broken, but it encourages others to do broken things

NM: I think that's a bit too cheery, some WSA people did want to do all that 'bad' stuff, so expecting graceful positive response to asking for an appendix saying "the good things we do here with EPRs are all you should do with them, don't do bad things"

RF: It's just another case of tunneling over http

HST remembers that it's not just http -- EPRs also are intended for use via JMS or carrier pigeon

DC/RF: We did say " for things that are resources, use URIs"

HST: Comes back to TBL's point about making it easy to understand when you need a name and when you need a set of property/value pairs to help you get some job done

TBL: are we resolved that "WSA's use of EPR is contrary to WebArch if it uses anything other than URIs to identify resources"

<DanC_lap> "those uses of WSA that use EPRs in ways that use parts of the EPR other than the URI for referring to resources are counter to the 'use URIs' principle of web architecture"

<noah> NM : are we resolved that "It is contrary to WebArch to use [Reference Parameters] as opposed to only the URIs to identify resources"

<noah> NM : are we resolved that "It is contrary to WebArch to use [Reference Parameters] as opposed to only the [Address] URI to identify resources"

<timbl> For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them.

NM: An EPR is (an XML EII) with an address and reference parameters, (all themselves EIIs) named with QNames

<DanC_lap> (is an address a URI?)

Candidate revision "Use of Reference Parameters as a replacement for URIs to identify resources is contrary to WebArch. For example, WSRF's use of Reference Parameters to identify experimental results"

<DanC_lap> "those uses of WSA that use EPRs in ways that use parts of the EPR other than the URI for referring to resources are counter to the 'use URIs' principle of web architecture"

<timbl> +1

<DanC_lap> "those uses of WSA that use EPRs in ways that use parts of the EPR other than the URI for identifying resources are counter to the 'use URIs' principle of web architecture"

<noah> +1 modulo grammar tightening

<Norm> +1

<DanC_lap> PROPOSED, contingent on DaveO's agreement

<noah> Noah notes that WS-RF is a framework comprising a number of specs. I believe the spec in question here is actually WS Resource Properties ( http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-04.pdf)

"Use of Reference Parameters other that epr:address to identify resources is contrary to Web Architecture"

<DanC_lap> yes, that says the same thing more concisely

<Norm> sure

"Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch"

<DanC_lap> +tim's example

<DanC_lap> 2nd

<Roy> +1

RESOLVED, pending DO's agreement, for discussion ASAP



<Norm> http://www.w3.org/2001/tag/doc/namespaceState.html

NW: xml:id raised the "can you add names to a namespace" question, we did it and are not sure it would ever _not_ be OK

<noah> Grammar issue: The antecedent of "they SHOULD" seems ambiguous.

RF: XML should be extensible by default, so I don't like the assumption that you have to say something to make this true

<DanC_lap> hmm... good point; in general, resources are allowed to change state; if someone wants to say otherwise, very well.

<Zakim> HT, you wanted to be unhappy about the ontology

TBL: So we should make the HTML may/must ignore the default for everyone?

<noah> Consider an element name <ns:width>. That's vocabulary that can be used in many languages.

RF: That confuses X and Y

HST: I'm concerned this confuses namespaces and languages

HST: When you see xml:banana for the first time, does this change the XML namespace? Of course not, it's just another one of the infinitely many expanded names that share http://www.w3.org/XML/1998/namespace as their namespace name part. My goal is to be sure we all understand and agree that it takes a lot more than a namespace to make a language.

NM: Back to namespace <-> language one-to-one point, there are many cases where it's true, but many cases where it isn't
... It is often the case in particular that the root element of valid documents is usable to identify a language, but that's not true of all elements in all namespaces
... That's not a corner thing, that's XML working as designed
... I like to look at meaning, processing is doing the right thing per the meaning
... Sometimes that's nearly context-independent, e.g. xml:id
... But it can be richly context dependent, so e.g. f:width is _not_ the width of my parent, but something else
... And again, that's XML, and it's good -- I can have something carefully documented to be a width, for use as a width, but the width of _what_ varies from language to language

<Zakim> DanC_lap, you wanted to concur with RF: it's not essential to say "this may change". That it may change is implicit; caveat consumer. Producer *may* give a policy about the future,

DC: I now think this does connect to versioning, but let's not go there now. . .
... I'm with RF on the point that it goes without saying that things may change, I shouldn't have to say so explicitly

NW: Namespaces do only one thing, give you a way of differentiating one set of names from another

DC: I don't accept that, namespace documents do lots of things

<noah> I'm pretty happy with what Norm is saying.

NW: This isn't about the change of such documents, its about change in namespaces, it would work whether their was a namespace document or not

DC: That's not the way anybody should behave, it's not consistent with WebArch

HT: I want this to be a SHOULD whether there's a NS Doc or not

TBL: Compromise: There SHOULD be an NS doc and it SHOULD be where you record the NS change policy

NM: We've already said the first half of this,let's not say it again in another place

<Zakim> Norm, you wanted to complete my thought

<DanC_lap> DC: please let it say "those who coin namespaces SHOULD state, +in the namespace document+, a change policy"

NM: You may know that four have been defined and used doesn't mean you can assume there will never be any more
... All this finding is about is establishing that, and the ways you can be more explicit

<Zakim> ht, you wanted to push compositionality

DC: Talk about resource in the representation of the resource

<noah> "those who coin namespaces SHOULD state, a change policy. If (as we have recommend elsewhere) you have a namespace document, then the policy SHOULD be stated there. "

HST: Compositional semantics: The meaning of the whole is a function of the meaning of the parts. Most things we have have this.
... This is good.

<DanC_lap> (I think HTML is not compositional; <blockquote> is semantically opaque)

<noah> Does CSS break this?

<noah> Restating so you can find it easily: "Those who coin namespaces SHOULD state, a change policy. If (as we have recommend elsewhere) you have a namespace document, then the policy SHOULD be stated there. "

<Norm> In the absence of any statement, the owner can do what they want,

NM: That seems close to consensus.

<DanC_lap> (I gather we're resolved on noah's "those who coin..." above, and publication of the finding with that amendment and one per Roy's note that owners have the right to change namespaces without notice. and I'm content to close this issue)

RESOLUTION: With the two changes requested above, this will be an Approved Finding

NM: Will try to do this for 11 October

VQ: What happens next week?

NW, HST, NM regrets

RF will be home, but would prefer to skip

VQ: 27 September is cancelled
... 4 October is next telcon

RF to scribe 4 October

Meeting adjourned 1700

Thanks all around

<timbl> http://www.w3.org/2005/09/2-tagmem-irc-minutes.html: draft minutes from Tuesday morning 20 September

Summary of Action Items

[NEW] ACTION: DanC to ask for "default nature" to be changed to "implicit nature" in RDDL spec [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action02]
[NEW] ACTION: DanC to derive RDF/RDFS/OWL version of terminology from whiteboard / http://www.w3.org/2001/tag/2005/09/22-diagram1.png [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action03]
[NEW] ACTION: Dave O to update finding with ext/vers [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action01]
[NEW] ACTION: DO and NM to continue and extrapolate the versioning work DO et al have been doing already, updating the terminology section. [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action05]
[NEW] ACTION: Henry to make sure that what he is doing with ontology of XML infoset fits with what DanC is doing on ontology of Language etc [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action04]
[NEW] ACTION: TBL and NW to write a draft of Nadia and Dirk first semantic web book [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action06]
[NEW] ACTION: VQ to write "Thank You" to Dave Berry, David Snelling, with cc to Malcolm Atkinson and Dave De Roure Dave Berry <daveb@nesc.ac.uk>, David.Snelling@uk.fujitsu.com, [recorded in http://www.w3.org/2005/09/22-tagmem-minutes.html#action07]
Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2005/10/11 14:02:40 $