IRC log of tagmem on 2003-07-21

Timestamps are in UTC.

19:55:46 [RRSAgent]
RRSAgent has joined #tagmem
19:56:48 [timbl234]
timbl234 has joined #tagmem
20:04:49 [Norm]
Norm has joined #tagmem
20:06:08 [TimBL-YVR]
20:06:13 [TimBL-YVR]
TimBL-YVR has changed the topic to:
20:12:21 [TimBL-YVR]
Agenda: 13:00 Start: setup time for those with windows
20:12:23 [TimBL-YVR]
13:10: Start for those with Linux
20:12:24 [TimBL-YVR]
13:14 Start for those with Macs
20:12:26 [TimBL-YVR]
13:15 Item one.
20:12:55 [TBray]
TBray has joined #tagmem
20:13:04 [DanC_jam]
DanC_jam has joined #tagmem
20:14:47 [Norm]
20:16:00 [IanYVR]
Resolved to thank BEA, Schemasoft, Antarctica!
20:16:17 [IanYVR]
Roll call: SW (Chair), PC, DO, TBL, NW, DC, TB, IJ (Scribe)
20:16:25 [IanYVR]
Expecting: CL, RF
20:16:36 [IanYVR]
Previous meeting 14 July
20:16:41 [IanYVR]
20:17:13 [IanYVR]
Resolved: Accept meeting of 14 July
20:17:34 [IanYVR]
20:18:14 [IanYVR]
SW: Several big themes: (1) Arch Doc to last call? (2) RDDL (namespaceDocument-8) (3)Close findings
20:18:42 [IanYVR]
[Review of agenda]
20:24:00 [IanYVR]
Next meeting?
20:24:51 [IanYVR]
28 July.
20:24:54 [IanYVR]
20:24:57 [IanYVR]
November ftf?
20:25:16 [IanYVR]
PC: The AB is not meeting on Sunday in Japan.
20:26:06 [IanYVR]
Proposal to move TAG ftf meeting - 15, 16 Nov
20:26:20 [IanYVR]
Proposal: 20, 21 Nov
20:26:24 [IanYVR]
TBL: Team day is 20 Nov
20:29:22 [DanC_jam]
so that's RESOLVED (15/16Nov) contingent on hearing from Chris, Roy.
20:30:57 [IanYVR]
20:32:18 [IanYVR]
20:32:46 [IanYVR]
TBray: Should XSLT that transforms RDDL to RDF be included in an appendix of RDDL Note? Should we say anything about standing of that RDF?
20:34:00 [TBray]
20:34:41 [DaveO]
DaveO has joined #tagmem
20:37:39 [IanYVR]
TBray: I have not yet created modular DTD.
20:38:05 [IanYVR]
SW: There's an issue about whether we should use XLink or not (per our other discussions about linking).
20:38:41 [IanYVR]
TBray: Original version of RDDL used XLink, but that seemed like a bad use of markup. There are well-known distinguished semantics in RDDL that would be stretching XLink semantics.
20:38:57 [IanYVR]
TBray: Also, this is the smallest possible solution, which I thought would be the best.
20:39:03 [IanYVR]
Action PC 2003/04/07: Prepare finding to answer this issue, pointing to the RDDL Note. See comments from Paul regarding TB theses.
20:39:28 [IanYVR]
20:39:31 [IanYVR]
[Comments from PC]
20:40:19 [IanYVR]
TBray: My recollection is that the finding was going to (1) outline how we got here (2) say that it's a good idea to have a namespace doc and (3) RDDL is a candidate.
20:40:46 [IanYVR]
20:40:59 [Stuart]
Stuart has joined #tagmem
20:41:20 [IanYVR]
PC: There was a sticky point in the original theses about the use of URNs.
20:41:56 [IanYVR]
PC: There is no record of the TAG agreeing with all of the theses.
20:42:02 [IanYVR]
DC: We don't have to agree with all of them.
20:42:21 [IanYVR]
TBray: I think there was broad consensus about most of them except the last couple, #5, and #6.
20:42:45 [IanYVR]
TBray: I propose that we:
20:42:58 [IanYVR]
1) With the blessing of the TAG, revise the Note to provide a more obvious example.
20:43:06 [IanYVR]
2) Dig up XSLT-to-RDF transform and put in appendix.
20:43:29 [IanYVR]
3) PC writes a finding that says namespace docs can be useful and here's a Note that defines a format specific to this application.
20:43:57 [IanYVR]
TBray: I don't think we need to address all of the theses for us to finish this issue.
20:44:10 [DanC_jam]
ack danc
20:44:10 [Zakim]
DanC_jam, you wanted to test the queue and to play thru some scenairos: RDFS, XHTML, some namespace 'defined' with an XML Schema, some WSDL example
20:44:22 [IanYVR]
DC: I'd like to (1) See three examples of RDDL since it has costs and benefits and (2) I'd like the finding to say that xml schema is another opportunity.
20:44:32 [IanYVR]
20:44:49 [IanYVR]
DC: I'd like examples with RDFS, XHTML, XML Schema, WSDL.
20:45:54 [IanYVR]
TBray: I think that it would be useful to put a RDDL document at the end of an RDFS namespace; for improved understanding of RDF Schema terms.
20:46:48 [IanYVR]
DC: Suppose we have as a namespace name.
20:46:57 [IanYVR]
DC: What would my browser show?
20:47:23 [IanYVR]
DC: How do I find RDF triple for subClassOf?
20:47:59 [IanYVR]
TBray: RDDL would point to a directory....
20:48:20 [IanYVR]
[DC draws RDDL document that links to another document with RDF assertions associated with subClassOf]
20:49:09 [IanYVR]
DC: Will the files (.rddl and .rdf) have the same names? I want to use content negotiation.
20:50:10 [IanYVR]
TBray: I think that in some cases you would want to use content negotiation (especially RDF case).
20:50:34 [IanYVR]
[Examine case where file names are different]
20:50:38 [IanYVR]
[I.e., conneg not used]
20:50:53 [IanYVR]
[Chris joins meeting]
20:51:53 [IanYVR]
TBray: So in this example, use nature"= "...rdf-syntax" and purpose = "formalDescription"
20:52:39 [IanYVR]
TBray: You could have another document in .n3, with nature="n3" and purpose="formalDescription"
20:52:47 [IanYVR]
DC: What is content type of .rddl document?
20:53:34 [IanYVR]
TBray: application/rddl+xml or application/xhtml+xml
20:54:03 [IanYVR]
TBray: Most (modern) browsers will handle application/xhtml+xml
20:54:11 [IanYVR]
DC: I get a "save as dialog".
20:54:19 [IanYVR]
TBray: Then you might have to serve as text/html...
20:54:44 [IanYVR]
DC: If we use "text/html" we have to put the HTML WG in the critical path and they'll say no.
20:56:06 [IanYVR]
[See xhtml 1.0 for guidelines on usage of text/html and application/xhtml+xml]
20:56:29 [IanYVR]
DC: I don't have any problem with rddl+xml.
20:57:29 [IanYVR]
DC: I think the RDDL spec needs at least a finding on content type.
20:57:39 [IanYVR]
20:59:04 [IanYVR]
TBray: The RDDL drafts come with a list of canonical natures and purposes
21:00:09 [IanYVR]
TBL: You should be able to get machine readable data without redirection (e.g., through conneg, by embedding RDF in RDDL, or by using RDF in place of RDDL).
21:00:19 [IanYVR]
DO: Another solution - put metadata in the URI...
21:00:40 [Norm]
21:01:44 [IanYVR]
TBray: TBL can put RDF at end of namespace URI if he wants. I would argue with TBL but we have no business forbidding that.
21:02:13 [IanYVR]
NW: What is compelling reason for having RDF right off the bat?
21:02:23 [IanYVR]
TBL: If you can get data in time t, why take it in time t2?
21:02:27 [IanYVR]
DC: It works todya.
21:03:47 [IanYVR]
TBray: TBL's applications are untypical, in my opinion. The most common uses of namespaces is to compare namespace URIs as strings.
21:04:28 [IanYVR]
TBL: It is a core design item of the sem web to be able to get info with only one link, not an indirection.
21:04:41 [IanYVR]
TBray: In my opinion, benefits of indirection are so high you'll end up doing this anyway.
21:06:02 [IanYVR]
PC: Why write a finding if there's no preferred format?
21:06:23 [Norm]
21:06:23 [IanYVR]
TBL: It's good to write a finding that says "It's good to put info at the end of a namespace URI."
21:07:39 [IanYVR]
CL: I don't see the point of a finding that doesn't make any recommendation about a format. Machines have no guarantee of what they'll finding.
21:07:57 [IanYVR]
DC: I think it's good to say "Here are some issues, they are approached different ways with different formats."
21:07:59 [Chris]
Chris has joined #tagmem
21:08:21 [IanYVR]
NW: I have found over last year that I would really like an indirection, and content negotiation is inadequate.
21:09:02 [IanYVR]
NW: It's a chicken and egg problem. APIs won't give indirection if there's no format out their they can know about.
21:09:21 [IanYVR]
NW: "May" use RDDL is good enough for me in a finding.
21:09:40 [IanYVR]
21:11:08 [IanYVR]
Straw poll: (1) Finding says that namespace docs are useful, enumerates some issues, points to RDDL. (2) RDDL Note published.
21:11:54 [IanYVR]
TBray: And in the finding, say that RDF has been useful for RDF applications.
21:12:23 [IanYVR]
Comfortable with that: NW, DC, TBL, CL, TB
21:12:39 [IanYVR]
PC: I want the finding to say that whatever is there should be human readable. We don't seem to be discussing that particular point.
21:12:58 [IanYVR]
q+ TBL, DC
21:13:24 [IanYVR]
TBL: I think that we agree that it's useful to have something human readable. But in a sem web application, the machine readable information is primary.
21:13:25 [DaveO]
q+ DaveO
21:13:46 [IanYVR]
TBL: There are other ways to make the data human readable (e.g., through a style sheet). Don't say "human readable as opposed to machine readable".
21:13:49 [IanYVR]
ack TBL
21:13:53 [IanYVR]
q- DC
21:14:20 [IanYVR]
TBray: I think we can say that there are substantial advantages to human-readability; sem web applications can, for reasons of performance, do other things.
21:14:34 [IanYVR]
ack DanC_jam
21:14:34 [Zakim]
DanC_jam, you wanted to ask if folks find human-readable
21:15:31 [IanYVR]
[Grumbling about level of human-readability of]
21:15:52 [IanYVR]
DC: If there are serious concerns about this being-human readable, I claim that "human-readable" not meaningful as a temr.
21:15:55 [DanC_jam]
21:15:55 [IanYVR]
21:15:58 [IanYVR]
ack DaveO
21:15:59 [DanC_jam]
21:16:42 [IanYVR]
DO: My recollection is the same as Paul's. The second that the Sem Web folks put machine-readable docs that aren't human-readable, the Web Services folks are likely to as well.
21:17:18 [IanYVR]
DO: I'd like the finding to say "SHOULD be human-readable" and MAY for RDDL.
21:18:13 [Stuart]
21:18:38 [IanYVR]
DC: My point is that an RDF document can be human-readable when displayed with style sheets.
21:19:07 [IanYVR]
PC: I don't think there's a way to make an XML Schema human readable in a way that meets my test.
21:19:08 [IanYVR]
21:19:17 [IanYVR]
CL: What's the test for human-readable?
21:19:21 [TimBL-YVR]
q+ to suggest a finding part saying taht machine-readable files can be made (more) human readable using various techniques.
21:19:48 [IanYVR]
PC: In many cases, a title at the top, "This doc defines the meanign of the namespace FOO. How it's used...what additional resources are available...purpose of namespace"
21:20:07 [IanYVR]
PC: Also include why someone might want to use the additional resources.
21:20:17 [TBray]
21:20:53 [IanYVR]
NW: Human readable is important, but not the only important thing; indirection also important.
21:21:07 [Stuart]
ack timbl
21:21:07 [Zakim]
TimBL-YVR, you wanted to suggest a finding part saying taht machine-readable files can be made (more) human readable using various techniques.
21:21:36 [IanYVR]
TBL: I propose that we say that human readability is a good idea. When you are publishing something that is machine-readable, here are some techniques - use style sheets, embed human-readable information.
21:21:58 [Stuart]
ack tbray
21:22:13 [DanC_jam]
hmm... the RSS case is an interesting case in point.
21:22:29 [IanYVR]
TBray: I would be ok with a compromise: (1) You should achieve human-readability (2) RDDL is an option.
21:22:56 [IanYVR]
TBray: And here are some techniques for making information human readable.
21:24:16 [IanYVR]
PC: I'd rather point out conflict in a finding than hide it.
21:24:31 [TimBL-YVR]
q+ to posose hat rather than conflict, tis be considered as a richness.
21:24:38 [TimBL-YVR]
q+ DO
21:24:43 [DaveO]
21:24:45 [DaveO]
21:25:08 [ndw]
ndw has joined #tagmem
21:25:15 [IanYVR]
PC: I don't want to "hide behind a SHOULD"
21:25:36 [Chris]
should means 'must unless you have an excuse'
21:25:48 [IanYVR]
PC: I think the TAG needs to give clear reasons for why one wouldn't put something human-readable at end of namespace URI.
21:26:52 [IanYVR]
ack TimBL-YVR
21:26:52 [Zakim]
TimBL-YVR, you wanted to posose hat rather than conflict, tis be considered as a richness.
21:27:19 [IanYVR]
TBL: There is a spectrum of applications from very human-readable to very machine-readable.
21:27:38 [DaveO]
q- DO
21:27:51 [DaveO]
21:28:10 [IanYVR]
PC: I think it would be useful to tell the community about the advantages of indirection.
21:29:18 [IanYVR]
PC: The finding should help new WGs avoid pitfalls by conveying benefits of human-readable, and indirection.
21:29:49 [DaveO]
Is this "Namespace document Best Practices?"
21:30:02 [IanYVR]
PC: If you have multiple schemas for the same thing, RDDL gives you advantages.
21:30:38 [IanYVR]
PC: If you only have one format and it's absolutely a characteristic of the application that performance is important, ok to use single format, but cost to losing human-readability and indirection.
21:31:00 [IanYVR]
PC: I want to avoid creating subgroups on the Web.
21:31:11 [TBray]
21:31:15 [TBray]
21:33:13 [DaveO]
21:33:18 [IanYVR]
ack DanC_jam
21:34:00 [IanYVR]
DC: I have an outline for a finding...
21:35:05 [DanC_jam]
21:36:12 [IanYVR]
ack DaveO
21:36:44 [IanYVR]
DO: I'm hearing PC argue for best practices on how to use namespace names. What kind of apps should dereference them.
21:38:41 [IanYVR]
[TB to summarize points for PC's finding]
21:38:50 [TBray]
Finding should say:
21:38:56 [TBray]
1. human-readability good
21:39:07 [TBray]
2. indirection good
21:39:20 [IanYVR]
3. Namespace doc good
21:39:44 [IanYVR]
PC: Usage scenario v. design scenario.
21:39:59 [TBray]
4. some risk in betting on some format being the One & Only Format
21:40:04 [IanYVR]
PC: There are advantages of indirectoin to have multiple different resources for human wnating to use the namespace.
21:40:42 [TimBL-YVR]
Point out the ability of RDDL to carry indirection.
21:40:59 [TimBL-YVR]
Point out the ability of RDF to contain arbitrary eg dublin core metadata.
21:41:29 [IanYVR]
TBL: Useful to have an example using RDDL and an example using RDF?
21:42:07 [IanYVR]
PC: I think the finding will give some examples of namespace docs.
21:42:30 [IanYVR]
TBray: For the Note, I've agreed to put some examples in, to include xslt script in appendix.
21:42:37 [IanYVR]
TBray: And say a few words on content type.
21:42:54 [IanYVR]
NW: You need to inline natures and purposes (i.e., put the list in the spec)
21:43:15 [IanYVR]
DC: Put some examples showing their usage.
21:43:31 [IanYVR]
NW: One of the natures should be "RDDL Document" (forward versioning)
21:43:48 [IanYVR]
21:43:56 [IanYVR]
q- TBray
21:45:02 [IanYVR]
PC: I think that reasons for publishing Note have slipped by.
21:45:12 [IanYVR]
PC: There might be other technical issues, we might want to register content type.
21:45:28 [IanYVR]
TBray: I think if we publish Note we've done our job.
21:45:51 [IanYVR]
PC: We should also send email to the AC explaining our position.
21:46:24 [TimBL-YVR]
21:46:26 [IanYVR]
IJ: I heard from AC meeting "Publish as Note first, then we'll figure out what to do."
21:47:26 [DanC_jam]
(did the minutes include tbray's RDDL todo? at the risk of redundancy: A: examples. B: XHTML DTD minutiae C: XSLT to convert to RDF, D: media type)
21:47:26 [IanYVR]
Action items for TB (RDDL Note) and PC (issue 8 finding) continued.
21:47:47 [Chris]
propose that we hold the 15:00 to 15:30 break now, ie 14:45 to 15:00
21:47:59 [Chris]
thus gaining 30 minutes for the next slot
21:48:14 [IanYVR]
DC: I'm happy to contribute text to PC's finding on content negotiation.
21:48:26 [IanYVR]
22:12:30 [Chris]
22:13:00 [TimBL-YVR]
22:13:06 [IanYVR]
Findings in progress
22:13:07 [TimBL-YVR]
metadata in URI
22:13:19 [IanYVR]
Draft finding from SW:
22:13:31 [IanYVR]
SW: Is "don't peek inside" enough advice?
22:13:44 [TBray]
22:13:51 [IanYVR]
SW: Questions about what one can infer from different pieces of a URI (e.g., resource nature from scheme registration)
22:15:45 [IanYVR]
SW: A number of perspectives: origin server (assignment authority) v. infrastructure (e.g., caches, libwww), v. applications
22:16:41 [Chris]
22:16:45 [DanC_jam]
ack danc
22:16:45 [Zakim]
DanC_jam, you wanted to suggest thanking for bray and cotton for taking their respective actions and break.
22:16:54 [IanYVR]
ack TBray
22:17:11 [IanYVR]
TBray: I think happy medium between minimal approach (DC) and SW's current finding.
22:17:58 [IanYVR]
[Roy joins meeting]
22:18:42 [IanYVR]
1) When you are processing a URI, there are normative specs (starting with [URI], then scheme specs); it's fine to peek inside URIs and interpret per normative specs.
22:19:01 [IanYVR]
2) Beyond that it's inappropriate to make other assumptions by peeking in URI UNLESS you have private agreements.
22:19:14 [IanYVR]
(i.e., rules published by the URI authority)
22:19:17 [DaveO]
22:20:12 [TBray]
22:20:16 [IanYVR]
ack DaveO
22:20:39 [TimBL-YVR]
q+ to ask for a summary of any substantial points made on the thread not compatible with the finding as is.
22:20:53 [IanYVR]
DO: I think that we need to describe when it's ok to peek inside a URI. And when it's ok to write a spec that says it's ok to peek inside a URI.
22:21:07 [IanYVR]
DO: I had an action item to talk to WSDL folks about why they want to peek inside their URIs.
22:21:30 [IanYVR]
DO: They have created a number of symbol spaces. Names are not unique across symbol spaces. They want to use the symbol space to differentiate items.
22:21:36 [IanYVR]
DO: (Issue 37)
22:21:55 [IanYVR]
DO: They want to have metadata in a well-defined format so that software can have predictability for how to process URIs in WSDL docs.
22:22:07 [IanYVR]
DO: So the WSDL spec would be a normative spec for how to interpret the URIs in WSDL docs.
22:22:24 [TimBL-YVR]
q+ to aska determining question of DO as to whther a non-WSDL-sware agent could be able to determine what is denote dby one of these URIs in the WSDL URIs.
22:22:29 [IanYVR]
DO: I think that there is at least one group that believes that an example of a "normative" spec is the WSDL spec.
22:22:35 [IanYVR]
q+ Stuart
22:22:37 [TimBL-YVR]
q+ Stewart
22:22:51 [DanC_jam]
ack danc
22:22:51 [Zakim]
DanC_jam, you wanted to ask how what bray is saying is different from what's written and to ask for an example of one of these WSDL non-opaque URIs
22:22:52 [IanYVR]
ack DanC_jam
22:22:54 [TimBL-YVR]
22:23:10 [IanYVR]
DC to TB: How is what you said different from SW's draft finding?
22:23:54 [IanYVR]
TBray: I think draft finding is too long, but I'm prepared to accept the assertion that SW's finding says what I mean.
22:24:17 [IanYVR]
TBray: Do people agree that it's ok for the WSDL folks to say how to interpret their URIs?
22:24:48 [DanC_jam]
somebody help me find the examples DO is talking about from
22:24:56 [TBray]
q+ Stuart
22:25:06 [TBray]
ack TBray
22:25:12 [TBray]
ack TimBL-YVR
22:25:12 [Zakim]
TimBL-YVR, you wanted to ask for a summary of any substantial points made on the thread not compatible with the finding as is. and to aska determining question of DO as to whther a
22:25:15 [Zakim]
... non-WSDL-sware agent could be able to determine what is denote dby one of these URIs in the WSDL URIs.
22:25:17 [IanYVR]
TBL: I have a criterion for this: suppose that someone has not come across the WSDL spec. Given a URI that was constructed according to the WSDL rules, can someone with such a URI (alone) determine that it's a WSDL URI?
22:26:12 [IanYVR]
TBL: E.g., do they get back a description (e.g., in a representation) of how to use the URI?
22:26:12 [DanC_jam]
ah... summary
22:27:16 [IanYVR]
DO: Part of issue 37 is to use the namespace name and frag id syntax that uses symbol space metadata. "Clever" use of frag ids.
22:27:39 [IanYVR]
DO: The domain authority can do what they want when they construct the URI. Then, the restrictions about the frag id kick in.
22:27:59 [TimBL-YVR]
DO: They plan to use a namesapce name with has a particular fradid syntax.
22:27:59 [TBray]
q+ to suggest that Section 1 of Stuart's draft could stand alone and solve the problem
22:28:14 [IanYVR]
ack Stuart
22:28:21 [TimBL-YVR]
q+ to say that if you want a funny fragid syntax you need a new mime type
22:29:40 [DanC_jam]
new summary 19Jun
22:30:01 [DanC_jam]
22:30:03 [DanC_jam]
The sample URI is
22:30:03 [DanC_jam]
22:30:03 [DanC_jam]
22:30:04 [DanC_jam]
22:30:06 [ndw]
ndw has joined #tagmem
22:30:37 [DanC_jam]
ack tbray
22:30:37 [Zakim]
TBray, you wanted to suggest that Section 1 of Stuart's draft could stand alone and solve the problem
22:30:44 [IanYVR]
TB Proposal: Section 1 of Stuart's draft could stand alone and solve the problem
22:31:34 [Chris]
q+ ndw
22:31:40 [DanC_jam]
I think I agree with bray that replacing the finding by its 1st section would be forward progress
22:31:53 [IanYVR]
NW: You can't say squat about meaning of frag ids until you get the representation with the proper content type.
22:32:29 [IanYVR]
TBL: I'm fine to talk about an imaginary document. But if you do retrieve it, you need to register a new content type or a frag id syntax.
22:32:45 [DanC_jam]
ack timbl
22:32:45 [Zakim]
TimBL-YVR, you wanted to say that if you want a funny fragid syntax you need a new mime type
22:32:46 [IanYVR]
DO: WSDL WG wants to register a new content type.
22:32:48 [Stuart]
re: specs defining patterns for using structure in URI assignments to name abstract things, how do you establish a chain to establish authority to make such an assignment? 2396 delegates assignment authority to URI schemes which in turn delegate onwards ultimately to some spec. or person or organisation. Such an authority could then explicitly state that they do infact make assignments according to the spec'd. pattern.
22:33:27 [DaveO]
22:33:29 [IanYVR]
DC: I second TB's proposal.
22:33:42 [IanYVR]
SW: There was feedback on the list that the parts after section 1 were useful.
22:34:02 [TimBL-YVR]
22:34:10 [IanYVR]
TBray: In an ideal world, I would leave section 1 and provide a bunch of examples.
22:34:11 [DanC_jam]
ack ndw
22:34:12 [IanYVR]
ack ndw
22:34:15 [TimBL-YVR]
q+ for examples
22:34:16 [IanYVR]
ack DaveO
22:34:44 [TimBL-YVR]
q+ to examples
22:34:55 [TimBL-YVR]
q- for examples
22:35:06 [IanYVR]
DO: I agree with section 1 with examples, including an example for what format spec designers can do. Also, what format spec designers should do about path components.
22:35:15 [IanYVR]
NW: I.e., using "/" instead of "#".
22:35:33 [IanYVR]
DC: I'm happy with DO's proposal.
22:36:52 [TBray]
22:36:57 [Stuart]
q+ Chris
22:37:19 [IanYVR]
RF: If a scheme does not provide for authoritative metadata, then it is normal to use the URI to get more information about what you might get back.
22:37:26 [TimBL-YVR]
q+ to ask Stuart to add a a mention that fragid needs mime type in 3.4
22:37:30 [IanYVR]
CL: If this is about HTTP only, we should say that.
22:37:42 [IanYVR]
CL: If about more schemes, we need to talk about RF's issue.
22:38:02 [IanYVR]
TBray: I think that the text as written is correct since it says that you can do what the spec authorizes you to do.
22:38:11 [DaveO]
22:38:40 [IanYVR]
TBray: So, for FTP, you can use path components for directory navigation.
22:38:41 [DanC_jam]
tim, why not consider ftp?
22:39:00 [DanC_jam]
ftp is how a significant part of the web is written
22:39:14 [IanYVR]
RF: I don't think we should make the finding specific to a URI scheme. Give an example of a relative normative spec that is providing policies for looking within the URI.
22:39:28 [IanYVR]
TBray: HTTP is distinguished in that other than the "/" there is no info you can use.
22:39:29 [Stuart]
22:39:43 [IanYVR]
ack TimBL-YVR
22:39:43 [Zakim]
TimBL-YVR, you wanted to examples and to ask Stuart to add a a mention that fragid needs mime type in 3.4
22:39:43 [DanC_jam]
ack TimBL-YVR
22:39:44 [TimBL-YVR]
ack tim
22:39:57 [TBray]
ack TBray
22:40:16 [Chris]
ack chris
22:40:31 [Roy]
Roy has joined #tagmem
22:41:21 [IanYVR]
RF: Section 1.1, part one - We need an example.
22:42:25 [IanYVR]
TBL: 2.2 and ff should be under 3 (stuff about HTTP)
22:42:52 [IanYVR]
TBL: "And if it's HTTP...."
22:43:06 [IanYVR]
SW: I'd prefer to not go into a particular scheme.
22:43:38 [IanYVR]
SW: For me, section 2 was about client perspective and section 3 was from perspective of assignment authority.
22:43:54 [IanYVR]
SW: I could merge the two and do each component from both perspectivies.
22:44:28 [IanYVR]
TBL: You need to say that the authority can never get to a server manager unless you have gone through a spec.
22:44:48 [IanYVR]
TBL: And you need to use registration mechanisms (e.g., for new frag id semantics).
22:44:55 [DaveO]
22:45:14 [IanYVR]
ack DaveO
22:45:52 [Chris]
q+ to worry about implying that inferring anything from scheme is also bad, which it isn't
22:45:58 [IanYVR]
DO: I think 37 depends on SW's finding.
22:46:33 [IanYVR]
[Veering into issue 37]
22:46:47 [IanYVR]
DO: One proposal is for metadata in path component v. fragment identifier.
22:47:52 [IanYVR]
RF: Not just putting metadata in the path. It's metadata that's to be interpreted by the client while inspecting the URI.
22:48:07 [IanYVR]
22:48:14 [DanC_jam]
ack danc
22:48:14 [Zakim]
DanC_jam, you wanted to ask that forms be one of the examples (perhaps redundant: other examples I agree would be good: making a new mime type that says how #blort works, and path
22:48:17 [Zakim]
... components)
22:48:56 [Chris]
old bad html forms?
22:49:09 [DanC_jam]
html forms are bad?
22:49:13 [IanYVR]
DC: And mime types say how mime types work.
22:49:19 [IanYVR]
ack Chris
22:49:19 [Zakim]
Chris, you wanted to worry about implying that inferring anything from scheme is also bad, which it isn't
22:49:21 [Chris]
hence their redisign, clearly
22:49:52 [DaveO]
Question: Can spec designers constrain the format of URIs to contain metadata in the path component of a URI?
22:50:35 [TimBL-YVR]
Yes lets discuss 0054.html . I disagree with 6 but agree with the rest.
22:51:07 [IanYVR]
SW: Question of whether mailto: URIs can only be used to refer to mailbox addresses.
22:51:15 [DaveO]
22:51:20 [IanYVR]
ack IanYVR
22:51:21 [TimBL-YVR]
Answer: No they should not
22:51:47 [IanYVR]
IJ: It seems to me that a single finding might cover both issues.
22:51:52 [IanYVR]
SW: That might be an outcome.
22:51:54 [IanYVR]
ack DaveO
22:52:17 [IanYVR]
DO: RF suggested that WSDL WG not use frag ids for metadata. RF suggested alternatives in the path component.
22:52:26 [IanYVR]
DO: Or use of ";"
22:52:42 [IanYVR]
RF: Traditionally identifiers are orthogonal to media type definitions.
22:53:37 [IanYVR]
RF: Putting metadata in URI puts a tie between how URI is constructed and how media type is constructed.
22:53:49 [IanYVR]
RF: It's worse to do this for the path component than for the frag id component.
22:54:21 [IanYVR]
22:54:31 [IanYVR]
10. Use a URI convention that slashes separate namespace URI and component
22:54:31 [IanYVR]
identifier. Posted by Roy at [11]
22:54:45 [IanYVR]
22:55:10 [TimBL-YVR]
q+ to say that you don't mess with th e URI space because if one lot contarin it then everyone else does and thy clash.
22:56:34 [IanYVR]
RF: The reason I included this option:
22:56:39 [IanYVR]
22:56:39 [IanYVR]
22:56:51 [IanYVR]
RF: It's associated with same level of hierarchy.
22:57:21 [Stuart]
22:57:56 [IanYVR]
DO: When using frag id solution, problem of inconsistent frag id semantics across different representation media types.
22:58:54 [IanYVR]
DO: As part of issue 31, we need to say something in conjunction with issue 8. If you want to put your own semantics into frag id, you can't use RDDL or conneg.
22:59:06 [IanYVR]
DO: If people want to use RDDL, they can't put metadata in their own frag id syntax.
22:59:10 [IanYVR]
ack TimBL-YVR
22:59:10 [Zakim]
TimBL-YVR, you wanted to say that you don't mess with th e URI space because if one lot contarin it then everyone else does and thy clash.
22:59:14 [Roy]
22:59:29 [IanYVR]
TBL: The primary req is that you can do the right thing when you dereference the URI.
22:59:36 [IanYVR]
TBL: I think that making the identifiers unique is reasonable.
23:00:32 [IanYVR]
TBL: I think that there other ways to ensure uniqueness other than by prepending class description, however.
23:01:13 [IanYVR]
TBL: The reason that you don't establish conventions for how to interpret the last few pieces of the path is that you lose if anybody else defines semantics for the same components.
23:01:30 [IanYVR]
TBL: This part of the URI is not your space. This is server manager space.
23:01:51 [IanYVR]
TBL: You can't control what people do with URIs. The architecture is that this is internal to the server.
23:01:52 [DanC_jam]
ack danc
23:01:52 [Zakim]
DanC_jam, you wanted to ask how an arbitrary party "groks" this example URI
23:02:34 [TBray]
23:02:35 [IanYVR]
DC to DO: Do you have questions about the solution with the hash in it?
23:03:18 [IanYVR]
DC: Earlier TBL asked how an arbitrary party figures out that a URI is governed by the WSDL spec. I'd like to walk through that.l
23:04:08 [IanYVR]
Example URI: "http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest"
23:04:11 [TimBL-YVR]
The server writer and the server administrator own teh URI space on a server. As WSDL spec writer, you can't put constraints on that space, or there will be horrible clashes. The URIs on web servers are generated from exposed foreign systems, databases, etc.
23:04:27 [IanYVR]
DO: One of the issues is that, without a frag id, you don't know where the end of the namespace is.
23:04:59 [IanYVR]
DO: If you use this syntax, you can't get back to WSDL spec.
23:05:22 [IanYVR]
NW: You can dereference the URI.
23:05:46 [IanYVR]
NW: Send back the WSDL document.
23:06:11 [IanYVR]
NW: You can't tell what the URI means without the deref; but that's the same issue with the frag id solution.
23:06:13 [DanC_jam]
ack roy
23:06:22 [DaveO]
I was wrong, Norm's right..
23:06:37 [IanYVR]
RF: It's also fair do assume that if RDDL is going to be used as a descriptive text, that it's capable of defining an arbitrary number of frag names in the description.
23:07:41 [DanC_jam]
(if you continue that line of thought, you'll end up with RDF)
23:07:53 [IanYVR]
TBray: If you are putting metadata in a URI, it's at least questionable; this gets in the way of server administration.
23:08:10 [IanYVR]
DO: See option 9 for put semantics in RDDL frag ids.
23:08:40 [IanYVR]
TBray: Seems to me that the WSDL folks are pushing up against limits of what's comfortable to do with URIs.
23:08:51 [TimBL-YVR]
q+ to suggest the customer is right
23:09:23 [Stuart]
23:09:45 [IanYVR]
TBray: One could, for the RDDL media type, allowing redirection of a piece of a frag id to be interpreted according to the media type of the related resource.
23:09:49 [IanYVR]
DO: That's option 9.
23:09:51 [ndw]
ndw has joined #tagmem
23:09:59 [DanC_jam]
ack tbray
23:10:18 [IanYVR]
q+ Norm
23:10:23 [IanYVR]
q+ me
23:10:27 [IanYVR]
ack Norm
23:11:06 [DanC_jam]
ack timbl
23:11:07 [Zakim]
TimBL-YVR, you wanted to suggest the customer is right
23:11:29 [ndwalsh]
ndwalsh has joined #tagmem
23:11:50 [IanYVR]
TBL: What the WSDL folks want to do is a variant of what the RDF folks have done.
23:11:57 [IanYVR]
TBL: And it's reasonable.
23:12:52 [IanYVR]
TBL: The point is that if you find one of these URIs in space, you need to be able to find the link back to the defining spec.
23:12:57 [DanC_jam]
ack ian
23:12:59 [Stuart]
23:13:06 [DanC_jam]
ack danc
23:13:06 [Zakim]
DanC_jam, you wanted to say that the WSDL folks are trying to give URIs to important resources
23:13:11 [TimBL-YVR]
RDF does this quite successfully.
23:13:33 [IanYVR]
DC: Bray observes that "it hurts when they do this"; I don't think we should tell them not to do this - we told them to give URIs to important resources.
23:13:53 [Stuart]
23:15:04 [IanYVR]
NW: How does it help if the WSDL document is an RDF?
23:15:56 [IanYVR]
RF: RDF has not invented any of this stuff....
23:15:59 [Chris]
nw: rdf fails the same way this fails - no idea what the fragment means until you retrieve the resource
23:16:21 [DaveO]
23:16:35 [IanYVR]
ack DaveO
23:16:51 [TimBL-YVR]
q+ to propose we recommend [3]
23:16:57 [TBray]
23:17:20 [Roy]
23:17:22 [IanYVR]
DO: For RDDL, we should look at this question of indirection, and how to include metadata in URIs that can be forwarded through RDDL.
23:17:26 [Stuart]
23:17:40 [IanYVR]
PC: In v1?
23:17:44 [IanYVR]
TBray: Yes. I think it would be useful.
23:17:47 [IanYVR]
ack TimBL-YVR
23:17:47 [Zakim]
TimBL-YVR, you wanted to propose we recommend [3]
23:17:47 [DanC_jam]
ack timb
23:17:49 [TimBL-YVR]
ack tim
23:18:22 [IanYVR]
TBL: The RDDL solution doesn't work with RDF. Anyone who uses RDDL has to put a wrapper around their frag id.
23:18:34 [Chris]
23:18:38 [Chris]
23:18:56 [IanYVR]
RF: If RDDL treats all frag ids as opaque strings....
23:19:10 [Chris]
23:19:14 [Chris]
23:19:25 [Chris]
look no parens
23:19:40 [IanYVR]
TBL: Suppose RDDL doc points to three alternative formats, you need to know format of related resource to interpret frag id semantics.
23:19:44 [Stuart]
23:19:49 [Stuart]
ack Roy
23:20:07 [IanYVR]
RF: Use flat namespaces.
23:20:23 [Stuart]
q+ DanC
23:21:00 [IanYVR]
ack DanC
23:21:02 [ndw]
23:21:07 [IanYVR]
ack DanC_jam
23:21:07 [Zakim]
DanC_jam, you wanted to suggest RDDL has union links
23:22:03 [IanYVR]
DC: I claim that RDF solves these problems. But if you want to have RDDL doc in between - if you want to interpret the frag id w.r.t. a RDDL document, you are saying you can use a fragment in any of the alternative related resources.
23:22:24 [Stuart]
23:22:43 [IanYVR]
TBL: This is only for the case of "ids".
23:23:16 [IanYVR]
ack ndw
23:23:18 [TimBL-YVR]
RDDL = Poor Man's Content Negotiation
23:23:35 [DaveO]
WSDL proposal does NOT use "ids".
23:24:08 [DaveO]
23:24:46 [Stuart]
q+ Chris
23:25:02 [Chris]
q+ to wish fragment identifiers identified fragments not 'you get to rewrite any spec'
23:25:04 [DanC_jam]
ack daveo
23:25:09 [IanYVR]
TBray: Could write RDDL spec to say that you can't interpret RDDL instance until you've
23:25:13 [IanYVR]
retrieved related resources
23:25:40 [DanC_jam]
using RDDL as the content of the HTTP 4xxx "multiple choices" would be pretty ideal.
23:25:42 [TBray]
can't interpret RDDL #fragment IDs against rDDL itself, but agaisnt a related resource
23:25:43 [Chris]
deferred fragment attachment on indirection
23:26:07 [Chris]
so, can never point to a part of a rddl document, in consequence
23:26:23 [IanYVR]
TBray: The price of this is that you lose the ability to point to a thing inside the RDDL document itself.
23:26:28 [IanYVR]
q+ Roy
23:26:32 [DanC_jam]
ack chris
23:26:32 [Zakim]
Chris, you wanted to wish fragment identifiers identified fragments not 'you get to rewrite any spec'
23:27:30 [IanYVR]
TBray: When you register a media type you should specify the frag id semantics. It's perfectly ok to specify the semantics to be "This frag id doesn't apply to me; it applies to a related resource representation."
23:27:45 [DanC_jam]
(this conflict between pointing at parts of XML documents and pointing at 'abstract components' is well known in RDF-land, fyi... it's related to our RDF in XHTML issue, and our fragments in XML issues)
23:27:49 [IanYVR]
ack Roy
23:28:10 [TBray]
23:28:18 [IanYVR]
RF:Unless you use xpointer, I don't see any reason why the syntax wouldn't be identical for the WSDL document as it would be for the RDDL document.
23:28:50 [TBray]
q+ to say that you can to point into a RDDL document just fine
23:28:51 [IanYVR]
RF: E.g., if you use a dot-separated list of names as WSDL frag id syntax, there's no reason why that syntax and the RDDL syntax couldn't be consistent.
23:29:42 [Stuart]
23:29:57 [Stuart]
ack TBray
23:29:57 [Zakim]
TBray, you wanted to say that you can to point into a RDDL document just fine
23:30:30 [TimBL-YVR]
q+ to propose [3]
23:31:27 [IanYVR]
[Examining options of issue 37]
23:31:44 [IanYVR]
23:31:56 [IanYVR]
DO: Let's look at requiremens.
23:32:06 [IanYVR]
1. It must be possible to identify each conceptual element in a WSDL
23:32:06 [IanYVR]
vocabulary with a URI.
23:32:12 [IanYVR]
2. It should be simple to create and use the URI
23:32:16 [IanYVR]
3. It must be compliant with the URI specification.
23:32:23 [IanYVR]
4. It should be able to identify WSDL extensions, ala soap:binding,
23:32:23 [IanYVR]
soap:operation, soap:address, soap:body, soap:action, soap:fault,
23:32:24 [IanYVR]
soap:header, soap:headerfault, http:address, http:binding, http:urlEncoded,
23:32:24 [IanYVR]
http:urlReplacement, mime:content, etc.
23:32:35 [IanYVR]
5. It should be possible to use relative URIs for the abstract components
23:32:45 [IanYVR]
6. It should be possible to extract the type information from the URI.
23:32:56 [IanYVR]
7. It should be possible to retrieve a namespace name document given an
23:32:56 [IanYVR]
astract component reference.
23:38:39 [IanYVR]
DC: I don't buy all of the requirements.
23:38:41 [Chris]
comment on requirement 6:
23:38:43 [Chris]
23:39:07 [IanYVR]
DC, TBL: I don't agree with 6.
23:39:15 [Chris]
I can extract a type (dateTime) from that URI or rather, I can use that URI to identify dateTime type
23:39:16 [IanYVR]
TBL: Req 6 is architecturally harmful.
23:39:42 [Stuart]
q+ Chris
23:39:54 [Stuart]
ack TimBL
23:39:54 [Zakim]
TimBL-YVR, you wanted to propose [3]
23:40:09 [Stuart]
ack Dan
23:40:09 [Zakim]
DanC_jam, you wanted to note that issue 37 is now barely distinguishable from issue
23:40:15 [DanC_jam]
23:40:23 [DanC_jam]
I haven't gotten the floor
23:40:24 [IanYVR]
CL: People who define URIs can put whatever metadata they want in the URI.
23:40:35 [Stuart]
23:41:12 [Roy]
23:41:24 [Roy]
ack Chris
23:41:41 [DanC_jam]
ack danc
23:41:41 [Zakim]
DanC_jam, you wanted to note that issue 37 is now barely distinguishable from issue
23:42:07 [IanYVR]
DC: Issue 28 related - do frag ids refer to syntactic element or can they refer to abstractions?
23:42:32 [IanYVR]
DO: Issue 37 proposes a particular interpretation for issue 28. But if we recommend another solution for 37, it's not related (i.e., frag ids not used).
23:42:36 [Stuart]
ack Roy
23:42:50 [ndwalsh]
ndwalsh has joined #tagmem
23:43:04 [IanYVR]
RF: For req 5 - does "relative URI" mean relative to the namespace URI or unrestricted relative URIs?
23:43:22 [IanYVR]
RF: Only way you'll get unrestricted is if you don't use frag id syntax solution.
23:44:27 [IanYVR]
TBray: What are the identifiers used for in practice?
23:44:32 [Stuart]
23:44:39 [IanYVR]
DO: E.g., identification of input when building tooling.
23:44:41 [Roy]
23:44:52 [IanYVR]
DO: They might have a lookup to see what the name is.
23:45:10 [IanYVR]
DO: There's talk about, on the wire, specifying what an action is in a SOAP header and mapping that to the input.
23:45:30 [IanYVR]
TBray: Sounds like they want to do what URNs are designed to do.
23:46:15 [Stuart]
ack Danc
23:46:15 [Zakim]
DanC_jam, you wanted to ask that the record show that we has some comments and questions on requirement 5, 6, and 7, but that said, let's look at solutions in any order dave
23:46:18 [Zakim]
... chooses
23:46:21 [IanYVR]
DC: We've discussed the reqs to my satisfaction.
23:46:29 [Stuart]
ack Roy
23:47:30 [Roy]
23:47:37 [IanYVR]
NW, SW, TB: I can live with option 1.
23:47:56 [DanC_jam]
(paste pointer to list again, pls?)
23:48:05 [IanYVR]
23:49:19 [DanC_jam]
(we're talking about #2 now?)
23:49:31 [IanYVR]
DO: Sometimes WSDL docs are modularized; hard to constrain uniqueness constraint across WSDL docs.
23:49:42 [IanYVR]
TBL, NW, DC, CL, TB: Can live with option 2
23:49:56 [IanYVR]
RF: I could live with it as well, but I don't think it's a realistic solution.
23:50:06 [IanYVR]
RF: Too many names.
23:50:15 [IanYVR]
PC: That's why I didn't put up my hand.
23:50:37 [IanYVR]
RF: Lots of human error possible in generation in individual names.
23:50:45 [IanYVR]
[option 3]
23:50:57 [IanYVR]
Require Unique NCNames.
23:51:05 [IanYVR]
DO: You combine the symbol spaces into one.
23:51:33 [IanYVR]
DO: You combine the symbol spaces into a single space, within a particular WSDL document.
23:52:08 [IanYVR]
TBray: This is identical to choosing an id.
23:52:17 [IanYVR]
TBray: 3 is a flavor of 2
23:52:40 [IanYVR]
Option 4
23:52:43 [IanYVR]
Use XPointer
23:52:54 [DanC_jam]
(perhaps ask who prefers this option when asking who could live with it)
23:53:21 [IanYVR]
DO: I think this uses xpointer framework and element scheme.
23:53:38 [IanYVR]
{Nobody likes}
23:53:46 [IanYVR]
[Option 5]
23:53:54 [IanYVR]
Use element(), XPointer framework
23:54:11 [IanYVR]
CL: Problems with this option are fixable.
23:54:15 [IanYVR]
{But no strong support}
23:54:22 [IanYVR]
[Option 6]
23:54:28 [IanYVR]
Develop WSD specific Xpointer scheme
23:54:37 [IanYVR]
NW, CL: Can live with option 6
23:54:47 [IanYVR]
[Option 7]
23:55:00 [IanYVR]
Schema component designators
23:55:08 [IanYVR]
CL: Less ugly than 4!
23:55:22 [TBray]
Record to show that ones I don't vote for in some cases because I just don't understand
23:55:43 [IanYVR]
DC: Inasmuch as option 7 is not good for WSDL, I don't think that it's good for schema either.
23:56:07 [IanYVR]
PC: Schema's task is to define global and local things; different from WSDL task (global only)
23:56:25 [IanYVR]
NW, CL: Could live with 7
23:56:34 [Roy]
23:56:57 [IanYVR]
ack Roy
23:57:48 [IanYVR]
RF: Earlier I was going to say that info isn't metadata if it's necessary to identify the resource in question.
23:57:56 [IanYVR]
[option 8]
23:58:06 [DanC_jam]
(what Roy mentioned about 'not metadata' is the restrictive vs. non-restrictive clauses, as we discussed, Ian)
23:58:07 [IanYVR]
8. Use namespace name and new fragment identifier syntax. This is the
23:58:07 [IanYVR]
current WSD proposal.
00:00:22 [IanYVR]
ack DanC
00:00:53 [Stuart]
00:01:01 [IanYVR]
DC: I think that there's a risk, but not a violation. If you fetch the thing and get WSDL, you can get authoritative info. If you don't fetch it you take the risk that you're wrong.
00:01:22 [IanYVR]
DC: But someone else could have told you that the doc you get back is WSDL...
00:02:03 [IanYVR]
ack Chris
00:02:36 [IanYVR]
CL: What about ".....#/.../..."
00:02:43 [Stuart]
00:03:04 [IanYVR]
DO: So that after "# and before first "/" is symbol space.
00:03:40 [IanYVR]
CL: I believe it's much clearer to use functional notation, and there might be text after the end of the closing paren.
00:03:58 [IanYVR]
ack TBray
00:04:10 [IanYVR]
TBray: I find option 8 unpalatable.
00:04:27 [TimBL-YVR]
q+ to ask about qnames
00:04:40 [IanYVR]
TBray: RFC2396bis still says that the format and resolution of frag ids depends on media type.
00:05:15 [IanYVR]
TBray: Option 8 is at odds with this.
00:05:37 [IanYVR]
DC: If the guy doesn't fetch the resource, it's not that RFC2396bis has been violated, but person who has dereferenced is taking a risk.
00:07:32 [IanYVR]
DO: If one follows option 8, it will lead people to put WSDL docs at end of their namespace URIs, and if they don't they incur risk that frag ids will not make sense.
00:08:56 [DaveO]
00:09:15 [IanYVR]
RF: This is a restricted application; you're not going to ever want anything other than a WSDL document.
00:11:56 [IanYVR]
[To be continued...]
00:11:59 [IanYVR]
00:12:01 [DanC_jam]
(we didn't just adjourn?)
00:12:04 [IanYVR]
00:12:05 [IanYVR]
00:12:09 [IanYVR]
00:12:12 [IanYVR]
q- ""
00:12:43 [TimBL-YVR]
625 W22nd
00:13:17 [DanC_jam]
(did we resolve to begin at 8am tomorrow?)
00:13:24 [IanYVR]
[DO, PC]
00:13:47 [Chris]
00:14:27 [IanYVR]
"Separation of semantic and presentational markup, to the extent possible, is architecturally sound"
00:14:29 [ndwalsh]
ndwalsh has joined #tagmem
00:14:34 [DanC_jam]
no story?
00:15:10 [DanC_jam]
hmm... making up words... restylability
00:15:25 [IanYVR]
DC: The story should raise the issue.
00:16:00 [IanYVR]
Accessibility offers lots of good stories of why good to separate content and presentaiton
00:16:01 [TimBL-YVR]
51 muddles level of abstraction and level of detail
00:16:16 [TimBL-YVR]
00:17:50 [IanYVR]
q+ to say that the strongest resistance he's encountered when telling authors to design flexible content is that they don't like styling other than their original intention. They don't want users to override their intention, for example, even if content goes from unusable to usable.
00:18:18 [DanC_jam]
yes, figures please
00:19:21 [DanC_jam]
yes, well, Ian, I think it's useful for the TAG to let those authors know that they're fighting the medium. There's a time and a place for that, but we can and should be clear that it's not usually good.
00:19:34 [IanYVR]
I understand that.
00:20:00 [IanYVR]
I note that what CL is covered by the XML Accessibility Guidelines
00:20:09 [IanYVR]
s/what CL/what CL has said/
00:20:48 [IanYVR]
IJ: There are costs of separation - packing.
00:20:54 [IanYVR]
s/packing/packaging necessary
00:21:06 [IanYVR]
Sure that's a cost!
00:21:22 [IanYVR]
If I give you one file, that's easier to view than if there are 3 files to use a spec.
00:21:31 [IanYVR]
URIs are good, but we
00:21:46 [IanYVR]
do have to deal with people doing things offline.
00:22:13 [IanYVR]
XML Accessibility Guidelines:
00:22:25 [IanYVR]
Guideline 2. Create semantically-rich languages
00:22:31 [IanYVR]
2.2 Separate presentation properties using stylesheet technology/styling mechanisms.
00:22:55 [IanYVR]
2.11 Specific checkpoint for Final-form applications.
00:24:56 [IanYVR]
TBL: Sometimes you want to limit the amount of reusability.
00:25:20 [Roy]
00:25:21 [IanYVR]
TBL: Distinguish level of abstraction and level of detail.
00:25:30 [Roy]
00:25:37 [IanYVR]
q- IanYVR
00:32:04 [DanC_jam]
ack danc
00:32:04 [Zakim]
DanC_jam, you wanted to note the 'possible' in the title
00:32:31 [IanYVR]
I suggest "On the separation of semantic and presentation"
00:32:38 [IanYVR]
I suggest "On the separation of semantics and presentation"
00:33:36 [IanYVR]
[Discussion of length of finding...]
00:33:52 [IanYVR]
CL: For the moment it's exploratory...
00:34:02 [IanYVR]
ack Roy
00:34:41 [IanYVR]
RF: Change "abstract" to "detail".
00:34:50 [IanYVR]
RF: Or talk about granularity.
00:35:02 [IanYVR]
RF: Don't say "abstract"
00:35:12 [IanYVR]
DC: For me "abstract" worked.
00:35:44 [IanYVR]
00:35:50 [IanYVR]
RRSAgent, stop