W3C | TAG | Previous: 5 Jan teleconf | Next: 19 Jan
Nearby: Teleconference details · issues list (handling new issues)· www-tag archive
The TAG congratulated TBL on his recent honor.
[No proposal yet]
PC: I'll have this out by the end of this week.
See also open actions by owneropen issues
Issue qnameAsId-18
6 Jan 2004 draft finding by Norm Walsh "Using Qualified Names (QNames) as Identifiers in Content"
[NW reviews some of the comments raised]
<Zakim>DanCon, you wanted to ask if XQuery functions are extensible
DC: I saw Eliott Rusty Harold claim that namespaces perform no function in XQuery.
PC: I posted links to two msgs that were rebuttals. This was an xpath 1.0 feature. WG has not yet provided an official reply to his comment.
NW: I think we as talking about built-in functions. I wrote back and suggested that no changes were necessary. Explained that the finding covered this in the section on exceptions.
DC: Please publicly ack MSM's message on behalf of Schema WG.
PC: I don't think my comment should stop us from moving forward with this finding.
DC: I think it would be good to have a "Yes" from the Schema WG before moving forward. The arch statement says "You did it wrong." Henry asked us to confirm; we did.
Action NW: I will ask the Schema WG to review the finding.
NW: I didn't make any changes based on PC comments re: XQuery examples I wanted to mention xpointer specifically further down.
Action NW: Clarify first para of 4.2 with example.
DC: To my satisfaction we've already asked the XML Schema WG the question since we have qname info in the arch doc.
SW: We are trying to get the Schema WG to review the LC doc. But note that the finding and arch doc are talking of two different mappings.... The finding is about qnames to URI. IT's not about local name to URI
DC: I'm a bit lost...
SW: Issue 6 is about mapping from the space of qualified names to the space of URIs. The mapping in the finding is about how to get from a qname to a qualified name and a URI.
DC: There should be an example in the finding about how, with DSIG, the declaration is lost. When you take out of context, you lose a binding.
NW: I think that in practice, the spec says something about preserving namespaces. I think that DC recalls an earlier draft of the DSIG spec; but the Rec includes an appendix that explains how they handle this issue.
DC: Then we can cite that happily: The DSIG WG realized this and took it into account like this..."
Proposal SW: TAG approves this finding, modulo inclusion of an xquery proposal, and with the proviso that two people review it berfore we publish.
DO: I object. I think that the DSIG is critically important to describe in this finding. I like DC's suggestion of referring to the DSIG work and how they resolved the problem.
Action NW: Revise draft for review and then possible approval by TAG on 19 January.
<Zakim>DanCon, you wanted to ask if the "architectural" statement appears in /TR/webarch
Issue siteData-36
Tim Bray writing on siteData-36
TBray: I think Danny's posting is a Red Herring. It does highlight that there are groups out there that care about this. But I don't see an objection in his comments.
<Roy>I think he just wanted to clarify that his approach is consistent with ours.
TBray: There was support for what I wrote in the blog.
<Zakim>DanCon, you wanted to express discomfort with the idea that a web site is also a web page, i.e. something you can get a 200 reply about
DC: I'm still developing a mental picture of how this works. I find counter-intuitive that a Web site is also a Web page.
TBray: I think that it's useful to distinguish representations.
DC: A page about a Web site is interesting. Calling that page "the Website" is counter-intuitive to me.
<timbl>q+ to point out that this is Semnatic Web Architecture.
RF: The idea is that a site would consist of all the resources that have this relationship to another resource. Whether that resource has representations is irrelevant.
<timbl>Site representations: Must be machine-readable; may or may not say what pages are in the site; should condain information about epr-site using RDF properties.
TBray: I agree with RF that such a URI would identify the resource, not the representation (i.e., the Web page).
<Zakim>timbl, you wanted to point out that this is Semnatic Web Architecture.
TBL: I think the TAG is at a crossroads here. The discussion between DC and TB just now is about ground we've been over. My version of the four points is that
TBL: To describe this without using what W3C has developed formally (e.g., in OWL) would be a mistake.
TBray: I agree with TBL's "MAY" instead of "SHOULD". The notion of "having a representation", then we have a straightforward argument about useful concrete proposals.
DO: I think that it woudl be useful to solve a discrete problem showing both generic and specific techniques.
DC: Please tell me more about what people who want this want.
TBray: Robots, syndication folks want to identify a feed with a site.
<timbl>Example : web:site relationship between web page and site. A site is a group of information resources.
TBray: Associate a page with a site.
DC: TB, your use of "site" confuses me. If you ask me for URI of "ongoing" site, I would have identified the URI of your home page.
<timbl>example: web:forAllPrefix relationship between a site and a string, such that all pages which have a URI which starts with that string are members of the site.
TBray: I hear DC saying that we might use a different name for "site" to avoid confusion. Auto-discovery is another use case.
<Zakim>Ian, you wanted to say that Web Content Accessibility folks probably would appreciate this, for claims about accessible sites.
IJ: Relates to WCAG conformance -referring to a collection of pages.
TBL: Playing with this is a good idea. E.g., demonstration in RDF. It may be a good idea to show people how to do this. Avoid confusion between "the site" and "all the pages on the site."
TBray: I'm sensitive to what TBL just said. If you look at our issue 36, it's about site metadata, not the notion of a site.
DC: If you call it a "site description" that would summon the right model for me.
TBL: The site description can talk about the site in general, but it may also provide some information that trickles down. This is related to the PICS requirements (that were dropped since too specific).
<DanCon>yeah, often folks say things about classes that they mean about typical members of a class.
<timbl>Typically people will want to say, "All members of this site are under the CC licence 16". You can do this in OWL.
SW: There seems to be a bootstrapping problem - where do we put this?
<timbl>A demo would be good.
SW: There seems to be a bootstrapping problem - where do we put this piece of RDF so that people actually find it?
TBL: TB has suggested using an HTTP header. If we solve the (separate) RDF-in-HTML problem, then you can put RDF in HTML.
RF: It seems to me we are attacking the problem backwards. The notion of "site" is there - set of related resources. We assign an identifier for the site (a URI). You achieve no success by pushing off the question of "what's the site" to a different URI (one for the site description).
<timbl>q+ to say point of crder been here befroe - this is HTTPrange-14 complete
RF: Why don't we just use the URI of the site. We don't need the site description to establish the mathematical relationship among the resources.
TBray: People often conflate "site" and "home page". One interesting property of a site might be its home page.
<DanCon>(in reply to Ian's question about OWL, perhaps http://www.w3.org/TR/owl-ref/#someValuesFrom-def or http://www.w3.org/TR/owl-ref/#Restriction)
TBray: Ordinary people think about sites. The fact that people don't refer to sites with a URI is a shortcoming of the architecture. I disagree with RF; I think useful to be able to serve representations of a site description.
RF: I don't want to put the chicken before the egg. I don't think both have to exist before we suggest an implementation. I think people should figure out metadata relations first, then figure out how to create representations of site description later.
DC: Please explain how this would work, e.g., if I were a robot.
RF: I don't think this proposal has anything to do with robots.txt.
DC: I think we are on different planets.
DO: I'd like to hear the use cases described more clearly.
<timbl>http://www.foo.org/sitedescr#thisSite
<Zakim>timbl, you wanted to say point of crder been here befroe - this is HTTPrange-14 complete
TBL: Any way to avoid inventing a new HTTP header?
<DanCon>(hmm... how to get at HTTP headers in cwm... does the python API expose that in a straightforward way?)
TBL: There are overhead issues with headers. E.g., server config files.
<Stuart>(hmm... could it go in Heads and meta's)
TBray: Re use cases- most of them fall into the auto-discovery bucket.
[IJ reiterates that for WCAG WG, the issue is identifying a set of things for the purpose of conformance.]
IJ: There are scenarios where human intervention is interestnig - human needs to check if pages satisfy WAI Guidelines.
Action TB: Beef up use cases in draft finding.
TBray: I think DC should provide a site description....
Action DC: Propose example of a site description .
TBray: I have been getting support from the field on this issue; I think we can perform a service to the community on this.
DC: Do we have a straightforward way for people to register their interest in an issue?
<Roy>To answer Dan's question, robots.txt exists to provide a safe-step for robots that do not have any information about the URI aside from its reference. Its purpose is to discover the server administrator's demands, not the desires of the website author. It would make sense to extend robots.txt to allow the reference to site resources that would, effectively, delegate the rules of robots.txt, but that would not eliminate the need for robots.txt itself.
DC: One way is to create a new mailing list.
IJ: How about a WBS form?
<Stuart>http://lists.w3.org/Archives/Public/www-tag/2004Jan/0007.html
IJ:(I am not sure how interaction with public works with WBS.)
Resolved: Close NW action item per his request.
PC: I suggest SW raise this with MSM as well.
<Zakim>timbl, you wanted to suggest XML c'n architectrue for discussion next week
DC: I18N and C14N are not far apart.
TBL: The solution might be in the XML Core area. Recently, the RDF folks adopted a canonicalization done by DSIG. The RDF group didn't feel that they wanted to design XML Canonicalization. Nor had the DSIG WG. There seems to be a need for XML Canonicalization. People are doing all sorts of things with pieces of XML; there's an expectation that if you do an operation and then its inverse, you end up with the same thing. W3C hasn't addressed this architectural aspect of XML I think it's slipping between the cracks. This could affect xquery . It's useful for (e.g., an RDF node) to carry a piece of XML. If you want to know when two pieces of XML are the same, you might canonicalize first and compare. But DSIG folks ignored xml:lang and preceded xml:base.
PC: "deep equals" in XML Query concerns equality of xml pieces. Everyone has their own verion of "equality". We don't seem to be get enough consensus about what "deep equals" means.
<DanCon>(hmm... perhaps this merits a new TAG issue; I think Martin argued that an RDF-specific equality over XML was appropriate; RDF Core argued it's a generic XML problem. Perhaps it's worth community discussion)
PC: From a staight serialization point of view, see xml query specs - any serialization spec will have some arbitrary rules that causes the xml infoset to be serialized in a particular way - you won't get an identify mapping with the original xml. You should be able to check that the serialization output, fed back into the serializer, shows that input and output are the same. Infoset not normative; you make references to infoset and identify the pieces that are important to your spec.
TBL: Xpath 2.0 datamodel replaces xpath 1.0 data model. The infoset doesn't provide a replacement function. In response to this question, the XML Core folks have said "look at your application; it'll tell you what you need".
PC: the very fact that different apps have different serialization reqs is manifest in the xquery/xslt serialization; it's parameterized. I think it will be hard to get an 80/20 solution to the serialization problem.
TBL: Then RDF doesn't have a chance since would be hard to provide lots of parameters.
SW: Is there a separate issue we should be raising here?
[Some movement that there is]
<DanCon>(not clear to me that this c14n stuff is different from xmlFunctions-NN)
Action TBL: Propose a new issue regarding canonicalization to www-tag. PC to respond with pointers to relevant specifications.
The TAG did not discuss topics below this line at this meeting.
Issues that are open and that we expect to close by the end of last call:
See also TAG findings