Agenda
See also: IRC log
<NM> Henry: I've also just emailed comments on the namespaces resource draft.
<scribe> Scribe: Rhys Lewis
<scribe> ScribeNick: Rhys
<DC> Jonathan, are you attending today? doesn't seem to say so
<SW> DC, Jonathan has an open invite from me to attend... apologies for not mentioning in the agenda.
<DC> ok
<DC> re ns8... I have an action on that issue; it's not on the agenda... if that's on purpose, that's good.
<DC> hmm... tracker doesn't show an action...
<DC> what happened to ?
<DC> oh... tracker doesn't automatically associate actions with the issue we're discussing. phpht.
<JR> hi, i'm here at stuart's invitation
<HT> Welcome Jonathan, SW told us you would be coming
<SW> DC... ahah... it has not been marked as relvant to nsd-8
<DC> I think I need to work on ARIA and namespaces during this time
<HT> So DC should read my new xmlFunctions-34 paper
<HT> see www-tag about 10 minutes ago
<DC> please continue ACTION-87; I told tracker
Scribe wonders if DC should be added to the regrets
<DC> hmm... calling in is perhaps cost-effective re xmlFunctions.
<HT> Rhys, don't encourage him!
<DC> not sure yet, Rhys
<DC> (stuart, I'm calling in for part; you'll please excuse me if I need to leave early)
<SW> ok
Agenda is at
SW: Minutes from 29/11 aren't on the public list yet. Would Henry do that please?
<DC> the norm is that the scribe announces the minutes
SW: Propose that we aprove those minutes?
<HT> I apologise for the late distribution of those minutes
SW: Hearing no objections, they are approved
... Next meeting Dec 13th. Norm has volunteered to scribe. Last meeting of 2007
<HT>
<DC> 27 November 2007
HT: Updated Draft document. Two major issues.
... didn't like the notion of elaborating namespaces, but elaborating elements
<DC> (cute sticky-note style... hope to view source on that one...)
HT: The other was about the granularity. One of the core issues is whether we should answer the default XML processing model question
... Is there some generic process of elaboration that most XML applications will want to have done before they start work themselves
<DC> (I think it's not about "most"; it's about what's licensed in the default case.)
HT: Generic XML processes, for example XInclude. Other candidates are decryption, signature checking, and interpretation of stylesheets
... There are others that have been mentioned
... Complex issues concerning the control of elaboration by the XML language. SOAP intermediary should not do XInclude, for example
<NM> Dan, see my comment in email just sent (). One of my concerns is that the current draft suggests that particular languages like XSTL can opt out on a per-language basis. That breaks what I think is important: which is that you can find any XML document on the Web and infer that (at least) the default interpretation applies.
HT: Control of where processing might happen.
<SW> Hmm... interesting... I though that some SOAP use cases invoved sig gen/checking by intermediaries.
<DC> good to know, NM
HT: The original document talked about elaboration for the whole XML document. Issue raised because might need finer grained control
... The current draft still has that issue.
DO: Could you use partial decryption as an example
HT: yes.
<JR> DC, I only know about it vaguely. thanks for the pointers. (and I don't know how to do the italicized aside in IRC as you have done, sorry)
DO: Credit card numbers are a good example, where they may need to remain encrypted during the communication
HT: These issues would take the document a long way from where it is, so at the moment I haven't addressed it
... I've written a much more formal analysis of the compositional semantics of XML. There is a pointer on www-tag
... I have now got a definition that interleaves elaboration and language-specific semantics in what I think is the right way.
... There is a process situation in that the definition of the default processing model is in the charter of the XML WG
<NM> I'm not sure we should be doing this at all either. See my email just sent:
HT: The elaborated infoset document does now read more like a rec than a finding and as a result I'm not sure we should be doing it at all
<DC> (can we hand this text to them? or can we phrase our work as requirements? the process issue is less interesting to me just now, though, so I'm not q+ing)
DO: Are you suggesting that functions-34 has been overtaken by the working group?
HT: Something like that. We should send it to them, as input. Actually that's sending it to me! In fact the other paper I've just written might be more appropriate for the TAG
... It's more architectural
<SW>
HT: gets pointer to the other document
<HT>
<HT>
<DC> (how about the tex source? I'm interested to convert to HTML, not to mention MathML and n3 and such)
<HT>
SW: Don't think we will get to a discussion of this new document this week
... Just checked and functions-34 came from mixed namespaces-13 when it split into 3
<DC> (where do we get to ARIA and namespace, ht?)
SW: It was part of the follow your nose process from the media type
... Henry's document is about the structure of the XML document, and Tim's is more about the social issue
<HT> DC, in that there's implicitly a story about how one namespace hands off to another . . .
HT: Not true of the newer document
<Zakim> NM, you wanted to talk about goals
<NM> Discussing
NM: I wanted to point people to a mail that hits some of the same issues. It reviews the TAG document
... I think it skips past the goals a little to quickly, and I'm not sure that I like them.
<DC> (how did NM find out about the document? did ht send another msg before the one 10 minutes before today's telcon?)"
NM: Seems to be that the goal is the processing model
... Prefer to think declaratively. The goal is to say is there anything additional that you should infer from an XML document
... There might be a stepwise approach. But I thought that the idea was to have something that applied even when you don't know the semantics of the root element
... The goal might not be achievable, because different XML languages might need different default rules
... Would like to see us try and achieve the general goal if possible.
SW: Tim, I would like to hear your aim in creating this issue
TBL: +1 to NM. Henry, if you feel that XSLT should be taken differently, then we need to make that really explicit
... Unless we can define the exceptions to top down in a generic way, I don't think I'd be happy.
... TAG has been discussing this top-down approach for some time, and we probably have quite a good way of looking at it. Not sure that throwing it over the wall would be effective.
<NM> If media types had a more granular "mixin" model, then one could imagine a application/xslt+nonstdmodel+xml approach that would signal lack of standard interpretation. I don't think media types can quite do that in a way that seems comfortable.
TBL: a lot of the folks in the XML space are more comfortable with pipelines, than top-down
<Zakim> ht, you wanted to respond to NM -- I no longer believe in the universal goal
TBL: Would want to make sure that the group understands all the work we've done and in particular the top down nature before they start
HT: We probably want to discuss this at the F2F
... I agree with Tim. The new paper is an attempt to define the 'peeling the onion' process. The process that I referred to as elaboration, was the wrong thing to do, because it took two stages
... It said that first, you construct the elaborated infoset, and then you add the semantics of the actual languages
... NM is probably right that defining THE elaborated infoset is not a well defined goal in the TAG document, its actually not what anyone actually wants anyway
... I have mixed feelings about responding to NM's detailed comments, because I'm less happy about the approach
... I'd like to request that the TAG focus on the new document, to see if it matches our view.
NM: Should we review this as a potential TAG finding?
HT: Yes, I think that is what it is trying to be. It is a definition of an architectural approach
SW: sounds interesting, and sounds like mixednamespaces-13
HT: It's in there
NM: Sounds like we both discovered a similar set of issues. So I think it's fine to move to the new document as long as we understand what it's goals are
SW: Seems to me that I should establish an action to kick this off again. Will people review this?
<scribe> ACTION: DC to review henry's new document [recorded in]
<trackbot-ng> Created ACTION-90 - Review henry's new document [on Dan Connolly - due 2007-12-13].
SW: wonder if we want the XML wg to pick up the work on the old document?
HT: I think we should delay that decision until we have worked out what we want to do
DC: requests continuation of his action, and excuses himself from the rest of the call
SW: Think it would be useful for Henry to walk through the latest revision of the document. Would that be useful Henry
HT: I'd like to recapitulate what we talked about last week, with the new audience
<TBL> DC, is it today?
<HT>
<TBL> Congratulations and happy Birthday and It Isn't So Bad On The Other Side Of The Hill anyway, danc
HT: We did quite a bit of discussion in Southampton, and we overcame an issue that was because of different views of the problem in different communities
<HT>
HT: We now have a couple of recommendations about how to publish namespace information, because there are two different use cases
... The new document calls out the relationships for both cases
<TBL>
HT: The rest of the document was thought ok. The question is whether we are happy with the current version
SW: I'm still finding the arrows counter intuitive in the first diagram.
HT: I've added some text about that.
<HT>
HT: I call your attention to the sentence at the end of the first paragraph of the above section, which I added in response to your comments
... reads out the sentence that explains that the arrow direction is for compatibility with GRDDL 1.0
SW: In GRDDL, what is the subject of the purpose?
HT: It's not expressed in RDF
SW: that's true, but it's written so that it can be mined and turned into RDF
HT: A purpose is an arcrole, which describes the purpose for which you would follow the arc
SW: Ok, so its the purpose of the agent performing the action of following the arc
... I'll look at that again, because I find it difficult
HT: I sympathise
SW: Does anyone else want to comment
<Zakim> NM, you wanted to mention concern about namespaces being/not-being info resources
SW: The document answers the question about what to put at the end of a namespace URI
HT: We've reached more consensus about the ontology.
TBL: in 4.2 we talk about the semantic web case. I need to read the whole thing
<NM> Discussing:
SW: I'm on the hook for a review, as is Norm. Would be good, Tim, if you could raise concerns to Henry
NM: I made a point in an e-mail. There is something that I disagree with. It says that a namespace is not an information resource. I still think it probably is. I think Tim disagrees with me
<NM> "Since the Web resource that is the description of a namespace is clearly
<NM> distinct from the resource that is the namespace itself, the two should in
<NM> general have separate URIs. What should be done to facilitate finding
<NM> one from the other?"
NM: Maybe we could skirt around the question of whether a namespace is an information resource or not. Proposes the above text as a replacement.
<NM> Tim is saying: let's not define what a namespace is. I >think< my proposed resolution is consistent with that. It doesn't define a NS. It just suggests that a nS is clearly distinct from description(NS)
TBL: I think that we may be falling into a trap. We probably don't need to define what a namespace is.
<JR> ouch! i don't really get what "is" the namespace (thinking about RDF now), NM. seems dangerous to insist on separate uris since at least in RDFland an effort has been made for there to be only one thing
TBL: There is no path to a namespace as an object in the architecture, at least in the tabulator work
... I don't think that a namespace name is a URI
NM: I think on the XML side, we are encouraging people to do a GET on the URI in the xmlns attribute. It may be different in the RDF side
... The purpose of this finding is to define what a server should do when it gets a GET on that URI
... You are saying that XML says you should declare namespaces, and should use URIs for that. The resource that is identified by that URI is a namspace document
<SW> Tim, what does <> identify?
TBL: Yes. this finding will tell you what you'll find in the namespace document.
NM: Not comfortable with this yet, but I understand what you are saying now
... Suppose I create a namespace, with a few elements. Then I say that the URI is for the namespace description documents. Those might change over time, or I might have several versions
... Aside from RDF, I think that you can have multiple description documents for a given namespace. They might cover different aspects
HT: I'd like to noodle on that
<NM> I think you DO want to make semweb statements about namespaces
TBL: we've spent a lot of time on range-14 distinguishing a resource from a description of a resource.
NM: Suppose I want to use semweb to control use of a namespace. Suppose there is a separate namespace document. I might want to make a semweb statement about the author of the document, or who has authority to change the namespace
TBL: An ontology is a subclass of an information resource
NM: Someone could write statements about that ontology.
... Could the analogy in XML be to define a limited namespace document, could just have a list of the elements. Then there could be lots of other descriptions that say other things like, there is a relax schema over there
TBL: Because OWL is just RDF, you can point to anything. The ontology of HTTP headers, for example, has some content types, but then just points externally for the rest of the definition
SW: This issue started with work on RDDL and was motivated from the XML namespaces end of things. The discussion was about whether things are human or machine readable
TBL: I agree with Henry. We should elaborate the RDF architecture separately, because it has its own patterns.
... I don't think we should generalise across the XML/RDF divide.
SW: So should we omit the RDF material from the document?
<NM> +1 to Associating Resources with XML Namespaces
TBL: When there is an ontology and a mapping, we feel its well defined. Maybe we should make this about associating resources with XML namespaces and do something separate for RDF
SW: henry, how do you feel about that?
HT: I'd defer to the senior editor on this. Need to ask Norm
SW: Tim, will you do a review?
TBL: I think my comment on it is that one about XML and RDF
... I'll try and do a more complete review
SW: This particular document has a couple of review actions against it, which will bring it back onto the agenda
SW: Lots of recent discussion about redirection and issues about 303
... Thread about web client libraries not giving visibility to 303, which would be an issue.
... Was a suggestion about self-referential content location on the final 200 response
... Would allow information to get through to the application from the library.
... Doesn't run counter to the TAG advice. My position is that the libraries that do that are broken, and should at least allow an applciation to request that additional information
<NM> Some reluctance to mess up the on the wire content to work around limitations in libraries. The information is there on the wire if you want it.
SW: Also discussion about 302 vs 303, because of older agents. More of an issue because of the meaning of 302
<Zakim> TBL, you wanted to mention the threat to the http-range-14 closure and possibility to add headers
TBL: Yes, the libraries are broken. Actually, in the Firefox library you can register a listener that gets the redirection information
<JR> would be nice to have an http analog of Received:
TBL: Also, people have raised the possibility of a header on the redirect. Instead of the redirect, you return the information with a header that indicates what it is that is actually returned
<Zakim> ht, you wanted to say a header is not enough
TBL: It reduces round trips, the semweb people are happy and old browsers ignore the difference between the representation and the description
HT: I think there is a fundamental contract implied by the 200. I like the idea, but I think it needs a new response code too
NM: But doesn't that deny the interoperability because browsers know what to do with 200. The whole 200 family is defined as success
<JR> i'll test out 207s with some browsers
HT: I'll do some experiments to see what happens
SW: adjourns meeting