See also: IRC log
<scribe> Scribe: Henry S Thompson
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
<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:
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 }.
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
[break]
<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