W3C | TAG | Previous: 23 Feb teleconf | Next: 15 Mar

Minutes of 2 March 2004 TAG FTF meeting in Cannes-Mandelieu (France) and WG Liaisons

Nearby: IRC log | Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative (20min)

  1. Roll call: SW, MJ, DC, PC, RF, NW, DO, IJ. Regrets: TB, TBL, CL. Observers at various times included Martin Duerst, Kendall Clark, Ann Bassetti, and Philippe Le Hegaret; see IRC for other observers. For information on participants during liaisons meetings, see those sections.
  2. Accepted minutes of the 23 Feb teleconf
  3. Accepted this agenda?
  4. Next meeting: 15 March.
  5. Resolved to meet 9-11 August in Ottawa (Confirm).
  6. Currently, the TAG has no meeting scheduled for May 2004 or Nov 2004. The TAG reversed its 9 Feb decision to meet in May.

1.1 Review of open action items related to issues

The TAG expects to review the list of open actions by owner and to close any that are obvious to close. TAG participants are encouraged to review this list before the meeting, as well as other action items listed in this agenda.

1.2 Review of materials for plenary day

The TAG reviewed slides from Stuart, David, and Roy; see the plenary agenda for links and the IRC log for TAG comments on the draft slides.

1.3 Meeting planning

[DC reads from back of an envelope]

- Two months to process LC comments
- RDDL to Note in July 2004
- Draft of diagrams/formal view of Webarch for Nov 2004.
Other Milestones:
- Nov AC meeting
- Election end 2004
DC: I'm disinclined to put schedule on TAG slide at tech plenary.
PC: I think an oral statement that the TAG is currently concentrating on its LC comments suffices. At May AC meeting, we'll need to follow up with what we said in Yokohama to them.

2. Technical

See also open actions by owner and open issues.

2.1 whenToUseGet-7

[Ian]

Action DC: Provide TAG with pointers into WS specs where issue of safe operations is manifest.
DC: Progress on my action
[DanC_jam]
See email "Marking operations safe".
[Ian]
DC: There's a solution brewing. They have an issue on safe operations; see email. Please consider my action closed. Seems like progress in the right direction in the WSDL WG.
plh-tag: The WSDL has not decided about whether to integrate in WSDL 2.0; still under discussion.
DC: I think an update to the finding is in order; community not clear.
Resolved that DC's action is completed.
DC: The most useful thing would be to meet with the WSDL folks and show them proposed text for the finding (see section 6: "Ongoing Work on GET in Web Services"): "Section 3 WSDL 1.2 Bindings [WSDL] provides a binding to HTTP GET, which makes it possible to respect the principle of using GET for safe operations. However, to represent safety in a more straightforward manner, it should be a property of operations themselves, not just a feature of bindings."
DC: I'd be happy to leave this text alone.
plh-tag: The text is appropriate.
DO: The WSDL WG has accepted this as an issue. The WG will probably do this as an extension rather as part of the core spec. People will have a standardized way of doing the annotation.
DC: That won't be good enough for me.
[Discussion with the WSDL WG is a-brewin']
SW, IJ: Forward pointer to the WSDL issue might be worthwhile.
Action IJ: Update section 6 of get7 finding to cite WSDL WG issue #117
Resolved: DO's action is completed: "Ask WSDL WG to look at finding; ask them if marking operations as safe in WSDL is one of their requirements."
PC to PLH: Will WSDL WG give us comments on Webarch by deadline?
plh-tag: Don't know; I'll try to find out.
DC: Please let us know in any case.
IJ: I think issue 7 will be closed as of publication of the finding. I will publish and announce to www-tag.

2.2 Follow-up on namespaceDocument-8

2.2 Update on findings

[Ian]

Proposed: Accept 27 February 2004 draft of QNames finding?
SW: Publish these findings as WG Notes?
DC: I would support publishing as Notes.
PC: I think that publishing as a Note is too heavyweight.
SW: Janet has requested moving to Note since it makes life easier for Comm Team to publicize.
IJ: If you ask me whether it's a heavyweight process to put on TR page, I would say no (already pubrules compliant, e.g.)

2.3 Web Architecture Document Last Call

Review and acknowledge comments sent to public-webarch-comments@w3.org.

Let the record show that PC and DC have bet a dinner that at this rate we won't (PC) or we will (DC) get to Recommendation by 2005.

2.3.1 stickler2

Issue stickler2

[Ian]

From Patrick's comments ".. It is incorrect to suggest that there is any semantic relation between the meaning of a URI used as a namespace name and the meaning of terms grounded in that namespace...Strongly advise the removal of both this term from the publication entirely but particularly this incorrect definition (see discussion above). The assertion that every URI used as a namespace name denotes a namespace document is false."
[One problem that "namespace document" appears in the story; but is not defined in the webarch text.]
DC: Patrick is objecting to the term "namespace document".
DO: I think that I brought this up earlier in Vancouver. Why do we have this term "namespace document". I recall Tim Bray pushing back and saying that this is a colloquialism that people understand. A sort of "named representation".
NW: Namespace names only appear in the declaration of the prefixes for syntactic sugar.
RF: That would be saying that namespaces are not resources.
DC: Parallel -
href="chapter_on_ingredients"
<base href="http://www.example.com/recipes/">
<a href="chapter_on_ingredients">ing</a>.
DC: You don't expect to be able to follow the base URI ref; it's just syntactic sugar. I was reluctantly convinced by that parallel, but I still agree with the Webarch text.
RF: I would say that while some namespaces are not resources currently, it's better to think of them as resources and that they may have meaningful representations.
PC: Point also the QName finding, which refers to the functions and operators spec, where we are associating meaning to components.
NW: I don't think that would be a convincing parallel.
PC: Becomes more and more concrete as more people want to refer to things in the namespace.
IJ: Should we define namespace document (or reuse a definition)?: NS document is the colloquial name for a representation you get back by dereferencing a namespace URI.
[DanC_jam]
hmm... "If a namespace declaration binds PFX to I and the I can be access to get a representation, then the resource identified by I is a namespace document."
[Ian]
SW: Careful about use of "document" here.
PC: +1 to DC's text.
NW: +1
IJ: Will people say "No, the resource is the namespace."?
DC: We may get those comments. I don't take an opinion on whether the namespace is a resource.
[DanC_jam]
clarifying use of variables and fixing 2 typos: "If a namespace declaration binds prefix PFX to URI I and I can be accessed to get a representation, then the resource identified by I is a namespace document."
[Ian]
DC: Current dfn says URI identifies by a ns and a ns document. Unambiguous, but may not make you comfortable.
[DanC_jam]
defNsDoc2: "If a namespace declaration binds prefix PFX to URI I and I can be accessed to get a representation R, then R is a namespace document."
[Ian]
SW: Proposed - call this a "namespace representation" instead.
[DanC_jam]
defNsDoc2r: "If a namespace declaration binds prefix PFX to URI I and I can be accessed to get a representation R, then R is a namespace representation."
[Ian]
[RF on choice in other specs of "representation" over "document"]
[DanC_jam]
DO: you chose "representation" over "document"...?
RF: to distinguish compound documents from representations of components.
[Stuart]
defNsDoc3skw: "The term NSD is a colloquial term that is intended to 'mean' a representation of a namespace."
[Ian]
NW: The story is pretty clear that we mean representation of the resource (by "Namespace document")
Straw poll:
DC: Anyone understand defNsDoc2? DC: Anyone understand defNsDoc2r? DC: Anyone understand defNsDoc3skw?
NW: I prefer 2 or 2r
DO: I prefer 2 without variables
RF: 2r
PC: 2 without variables.
SW: 2r without variables
MJ: 2r without variables
DO: I don't like 2r. People in the community say "namespace document".
[Norm]
If a namespace declaration binds a prefix to a URI, and that URI can be dereferenced to get a representation, then that is a namespace representation.
[Ian]
IJ: Maybe it's useful here to combine 2r and 3skw to say "We are explicitly saying here that a namespace document is a representation of a resource, and that the resource is a namespace, not a namespace document."
RF: I disagree with IJ.
[DanC_jam]
DC: I'm pretty sure timbl means the resource, not the representation, by "namespace document". I feel obliged to object on his behalf.
[Ian]
RF: I like NW's.
IJ: Modifying NW's proposal If a namespace declaration binds a prefix to a URI, and that URI can be dereferenced to get a representation, then that is a namespace representation. The TAG interprets the community's use of the phrase "namespace document" to be synonymous with namespace representation.
DC: Don't like "The TAG interprets"
Proposed to adopt NW's definition for Webarch as a substitute for namespace document: "If a namespace declaration binds a prefix to a URI, and that URI can be dereferenced to get a representation, then that is a namespace representation."
DC: I object.
DO: I abstain.
So resolved.
Action IJ: Incorporate text. IJ intends to tie "namespace representation" to "namespace document" in the document.
[Support for responding to comments one at a time]

Action NW: Respond to Patrick on this stickler2.

2.3.2 stickler5

Issue stickler5

[Ian]
Problem in stickler5 is phrase "resource is unreliable"
[Discussion of what "unreliability" means here - architectural, social]
NW: "Unpredictable" instead of "unreliable".
IJ: Is it worth talking about management of resource rather than resource as "unreliable" or "unpredictable"?
SW: I don't get that from the comments.
DC: I advise editor to change unreliable to unpredictable.
NW: I don't think that change addresses the substance of his comment.
[DanC_jam]
[breaking the incoming messages into parts is fraught with peril]
[thanks for trying, but please be prepared to revise]
[Ian]
Action IJ: s/unreliable/predictable (and inform reviewer).

2.3.3 stickler6

Issue stickler6

[Ian]

From Patrick's comments: "Para 3 seems to contradict the last statement of para 1. In para 1 it is said that POST requests and responses cannot be referenced by URIs, yet para 3 describes a means to do just that. It seems that what is meant to be said in para 1 is that, per the default behavior of POST, the request and response are not normally assigned distinct URIs by which they can be later referenced. ???"
DC: We could, in the story, say "The Webmaster didn't use "content-location" and therefore (...can't be bookmarked...)...". I propose a tweak to the story to address this issue.
RF: Para 3 is wrong. Content location header does not correspond to the POST transaction. Depending on the response code, it could mean that a new resource was created. Under no circumstances does it correspond to the POST operation itself. The section heading is weird.
Action IJ: Propose a new section heading for 3.5.1.
RF: Section makes more sense if not about "accounting". Two topics in this section:
  1. Paper trail
  2. Bookmarking results of POST
DC: But using content-location is like giving someone a receipt.
RF: That depends on response code.
DC: I'd like to advocate the use of content-location for tracking.
Ann Bassetti: I don't get the "unsafe" part from the current text.
MD: Is there any implementation experience for this?
DC: Suppose I say know.
MD: How do you move to CR if there's not much implementation experience for this.
RF: How about a section on accounting and another section on identifiers for post responses.
PC: On "email can be copied to public archives" note that email can be forged.
Action IJ: Review 3.5.1 and propose a revision to the TAG that more clearly distinguishes the two topics of bookmarking results of POST and paper trails (both safe and unsafe contexts).

2.3.4 stickler7

Issue stickler7

(Section 3.4, para 1, last sentence and Section 3.4, para 2:)
[Ian]
DC Proposal : Fold in text from finding http://www.w3.org/2001/tag/doc/mime-respect-20040225 and see what the impact is.
Text from finding: "To enable the greatest number of independent agents to interpret representation data in a consistent manner (i.e., according to a common set of specifications), the Web architecture adopts the first choice: representation metadata, when provided by the sender of a representation, is authoritative in defining the nature of the representation being sent."
SW: I prefer media type.
DC: "media type and other representation data" works for me.
[DanC_jam]
stickler's comment on 3.4 para 2 harks of PFPS's comments.
[if you're gonna break comments into pieces, please do it by document section.]
[Ian]
"Section 3.4, para 2: The text of this paragraph is a bit too strong regarding URI owner's rights. The owner of a URI has the right to decide which representations of the denoted resource are accessible via that URI -- but in fact anyone has the license to create a representation of that resource,
and indirectly associate that representation via another URI that is declared (e.g. using own:sameAs) as semantically equivalent. I.e. the rights of the owner of a URI are limited to the access of representations via that particular URI, not (necessarily) to total control of the resource denoted as well as any and all representations of that resource (accessible via other URIs)."
DC: this is related to PPS's comments
[No resolution]

2.3.5 clark5

Issue clark5

[Ian]
Section 1.2.3
http://www.w3.org/TR/webarch/#general
http://www.w3.org/TR/webarch/#error-handling
DC: Example of when not harmful?
Excerpt: "mere failure to notify isn't always a harm."
RF: Some may be improved by recent changes to the finding.
Kendall Clark (KC): If my user agent does what I want it to do, without notifying me, then that's ok by me.
RF: The reason that silent recovery is harmful is that it prevents the person who made the error from fixing it. There's no way for the technology to know whether someone is a first party or a third party.
KC: Adding a sentence about configuration might help the reader. I think it's ok when my user agent, per my instructions, does not notify me when certain types of errors occur.
DC: But this is a statement of principle.
RF: Move the description of "consent" from the finding to the Arch Doc.
NW: +1 to RF's proposal.
KC: Also, include RF's point about making errors known helps get them fixed.
Action IJ: Move some text from finding and clarifying statement.
PC: Recall my problem with this finding - IE developers feel that usability is important in the face of bad content on the Web. See IJ's text in the finding.
IJ: I am hearing "notification is not the only way to be non-silent".
DC: In particular, the user may have said something in advance (through configuration).

2.3.6 clark12

Issue clark12

[Ian]
clark12: Needless Propagation of URIs?
KC summarizing: I like that google registered "gogle.com".
NW: You get a redirect (302 moved)
DC: It would be bad if they gave you back a 200 ok
RF: That would be bifurcation.
IJ: The UA in this case hasn't recovered from error; the UA has just followed the protocol.
RF: In case of 302, there are two resources. You are publishing, on the server side, a connection between two resources.
2.1. URI Comparisons
http://www.w3.org/TR/webarch/#identifiers-comparison
DC: Could add a sentence about a redirect in the case where a URI to a second resource "leaks out". We had this problem with mod_spelling at w3.org. It was a nightmare.
Action IJ: Talk about good practice of using server-side redirects to connect two resources when people start using "the wrong URI".

3. Liaisons

See liaisons page.

Liaisons:

  1. SVG WG Liaison
  2. XML Core WG Liaison
  3. XML Schema WG Liaison
  4. Voice WG Liaison
  5. I18N WG Liaison
  6. Web Services Description WG Liaison

3.1 SVG WG [1 March]

Minutes are available in the SVG WG mailing list. TAG participants were Chris Lilley, Stuart Williams, Roy Fielding, and Mario Jeckle.

3.2 XML Core WG [2 March]

TBL joined the meeting by phone. From the XML Core WG: Paul Grosso (PG), Daniel Veillard (DV), Liam Quin (LQ), Richard Tobin (RT), Arnaud Le Hors (ALH), Jonathan Marsh (JM), Dmitry Lenkov (DL). Note that Norm Walsh is both a TAG participant and co-Chair of the XML Core WG.

  1. xmlChunk-44
  2. xlinkScope-23
  3. Comments on LC Webarch.
[Ian]
Resolved: This will be a public record.
[Ian]
SW: IJ, please send these minutes to the Core WG for their review as well as the TAG's.

3.2.1 xmlChunk-44

Issue xmlChunk-44

[Norm]
Yesterday's core minutes on xmlChunk-44 (Member-only).
[Ian]
Summary of xmlChunk-44
NW: Broken down into:
1) xml:lang
2) Encoding "just chunks"
NW: On xml:lang, considered adding a language property to the infoset to provide access to the inherited value. But the xml spec talks about xml:lang as representing "intent". WRT to passing pieces of XML, one thought was to strip down the original complete document -- leaving all of the desired chunk and whatever part of the original document outside the chunk that is required to provide the desired context (if any) -- and then to provide an xpointer into this stripped down document that locates the chunk proper. Another issue was canonical form to allow digital signatures. Core WG not inclined to take that on.
[timbl]
A large part of this problem is that many things have been left open by the core WG, but we need some defined *common* answers.
[Ian]
PG: Our suggestion re chunk passing seems to be a subset (logically) of what the interchange spec says.
timbl: Does that spec say whether you can compare chunks for equality?
PG: No. Equality of infoset would be the right place.
DC: But that's not defined.
NW: It's not clear what the semantics of equality means in a widely accepted way.
DC: While people don't necessarily agree, it would be really useful (to have an equality function).
PC: We are having a hard time figuring out what a default "deep equals" function does.
[Discussion of deep equals possibilities]
TBL: I agree with DC and want to point that there are times when the user wants to use XML as a data type.
[DanC_jam]
DC: how about this idea for chunk:equals: if it makes the same calls thru SAX, then it's the same.
[Ian]
TBL: But there's no equality function in this data type.
[TBL talks about TAG experience with URI equality stack]
TBL: Exclusive canonicalization will work for some cases. Can the bar be raised a little higher to include xml:lang. We are looking for a standard that says what the value space is. I agree that a lot of people will want their oar in the water. But if the XML Core WG doesn't do this, who will? I think that other groups don't have a mandate to get agreement on this.
MR: I think that not having default equality gives people incentive to think about what equality serves their purpose. I see lots of useful equality functions; I don't think there's one to easily standardize.
PG: Clarification - are we talking about equality at the infoset level or at a syntactic level?
[Zakim]
PGrosso, you wanted to ask TBL if he's talking about equality of serialized form or infosets
timbl, you wanted to explain to PG that these are fairly short step apart.
[DanC_jam]
yup, foo:equal will form an equivalence relation on any serialization mechanism.
[Ian]
[TBL defines a canonicalized form off the cuff]
TBL: I think that defining the equivalence class is harder than defining a canonical form.
[timbl]
Suppose you have an equivalence class of XML serialization, such that their infosets are deemed "foo-equal". Then I can define the canonical form as the smallest (in unicode standard sort order #15) of those serialization.
[Ian]
MR: There are already four canonicalizations I'm aware of. And there are some that are very useful for certain applications.
[DanC_jam]
timbl argues that c14n is not harder than equality, since any equality relation imposes an equivalence relation on serializations, and the first/shortest serialization can be declared canonical.
[DV]
there is no Infoset -> serialization function, there is corner cases where such a serialization is "tricky"
[timbl]
So the effort of defining a canonicalization is not much more than that of defining equality, the hard bit.
[Ian]
MR: Perhaps with more experience with domain-specific equality classes, we can abstract.
PC: Infosets are not concrete objects. The infoset spec only defines a set of terms.
TBL: I said "If you had an equality function for infosets....", i.e., you've solved that problem, then {and so on}.
PC: Serialization of xpath data model might make more sense, but there might also be problems with that.
DC: What's wrong with the solution "If it makes the same sax API calls."....then it's the same thing. My understanding of the Sax API is that if strings are different you'd have different SAX calls. I think there's a dfn lots of people would understand, which is "I get the same thing through the Sax interface".
RT: You could make a profile of a basic infoset and say .....
RT: You just have to profile the infoset.
DC: Of course when I talk about the Sax API calls I expect to be able to abstract from that specific API.
JM: People who need lexical comparisons don't benefit from this solution.
[timbl]
DanC, you didn't specify how much is inherited.
[Ian]
DV: PSVI's are not in the infoset model.
[Norm]
I don't see how or why inheritance should have anything to do with equality. If two things are equal, inheritance will work the same way in both cases
[Ian]
DC: xsi:nil is not relevant. I'm not talking about typed information. How is the solution I'm proposing not acceptable. or valuable?
[timbl]
DV, can you type that?
[Ian]
ALH: I agree with DC. I hear DC and RT saying the same thing - we can find a way to compare two infosets. I hear Michael saying for PSVI that that's not enough. But that's ok.
[DV]
character("foo" 3) ; character("bar", 3) would then be different from character("foobar", 6)
[Ian]
ALH: Other groups that define infoset extensions can extend the equality function.
[DanC_jam]
ah; good point, DV.
[DV]
it's just a specific counter argument for SAX API
[timbl]
Thanks DV
[Ian]
PG: I hear different opinions on whether an XML Core infoset equality function would be useful.
JM: We'd need to hear user needs.
DC: "who are the customers" is a good question. The customer I'm most familiar with (RDF) has already decided, so anything new is a burden to them, not a benefit. hmm.
[timbl]
I think the user need for things like databases is to be able to use XML as a rich text type for things like names, help field, descriptions, in a way which is context-free. This is a subset of applications. But it is a very common application.
[Norm]
The XML database community, in my experience, is much more interested in typed values than lexical values.
[Ian]
RT: If you wish to use infoset equality to describe xmlchunk equality, then recursive comparison of infoset terms would not suffice.
[DV]
NW: seems that's not solvable for 80 % of that community as PaulC said
[Ian]
SW: I think that other groups have said on the list that they are looking at general solutions re: inheritance of attribute values.
LQ: ID equivalence is another issue.
[Norm]
In the presence of user-defined types, I think you're right DV
[Zakim]
timbl, you wanted to say that the XPath data model seemed to work for DSig - if infoset don't want to define one. and to
[Norm]
I think Liam was specifically talking about the system identifier
[Ian]
TBL: To motivate this - people want to use XML in a simple way sometimes. E.g., in a database, where you are used to having Unicode strings, you want to be able to put a paragraph. People would like to be able to "stick in" some HTML.
[Liam]
I was trying to say you'd have to refine Dan's definition, as sax will likely return things like system identifier (the URI of the things you're comparing)
[Ian]
TBL: It's like rich text in email. It's context-free - just used for markup ... There's a sense in which there's a context break. Martin is saying "But what if the FAQ is in French"....i.e., what about xml:lang? People want to put links (html:a) in IRC, calendar entries, etc....
[DV]
I don't understand why the language of a string which is metadata about that string is not treated as other metadata
for that string like encoding, length, etc ...
[timbl]
If XML Fragment allows you a choice of what you inherit, it doesn't solve the problem.
[Ian]
ALH: Is the TAG's concern only about chunk equality? Is serialization something the TAG is interested in as well? Or just equality?
SW: My sense is serialization first, then equality. Carrying context into a serialization.
[timbl]
I thought I explained above that they are close. I think we need both.
[Ian]
DC: I think equality and context cause the issue to arise. The fragment solution is kind of interesting. That mights requirements until one person used xml:lang and the other person didn't and you want to compare.
RT: TBL's FAQ example makes this sound like a much less formal application than we were thinking.
[timbl]
Less "formal" application?
????!!!!! No one is "sticking" by hand
[Ian]
RT: There may be pragmatic solutions rather than solving the equality question generally (e.g., copy what you need).
[Zakim]
Norm, you wanted to return to JM's issue about who the clients are
[Ian]
NW: I can imagine writing a spec based on the infoset to explain what it means for two profiles to be the same. But I don't know who would use it. Comparing two infosets is fine; comparing two points in two infosets is another problem.
TBL: I don't know what "less formal application" means. We are talking about automating and therefore need a crisp solution. I think this is a serious application; there are a lot of places where XML isn't used but could be. Maybe we need to define a concept of a context-free XML Chunk. E.g., any XML can go here; you can put it in this box; this context has the following quality function.
DC: To illustrate the business of serialization interacting with the issue of equality:
- OWL is concerned with when things are equal and when they are not (e.g., medical databases).
DC: Product descriptions. People want to make sure, e.g., that a product is described consistently in all parts of a catalog. People were convinced that customers would want to do this sort of thing: serialization then equality. RDF Core WG picked Dig Sig canonicalization, but I18N WG unhappy with that solution.
PC: What about the qnames in context problem?
[Yes from the crowd]
[Discussion of namespaces/qnames/signing]
[DanC_jam]
I find PC's argument appealing, but I'm pretty sure the I18N WG didn't find it convincing, i.e. I think they heard it.
[Ian]
RT: By "informal" earlier I meant "the distinction between cases where the transfer of the data from the original context where the application doing the transfer knows what to do, from the generic context where the application knows nothing. I'm still not clear whether TBL is looking for a complete generic solution.
[Zakim]
PG, you wanted to respond to TBL's comment about xml frag allowing you a choice of what to inherit.
[Ian]
RT: Or whether the cases of interest involve knowledgeable agents, who can include relevant context.
PG: Nobody is giving someone a choice of what to inherit. The XML 1.0 spec is the one that talks about inheritance. I thought that a chunk spec would not have to talk about how to inherit, only how to put context onto a chunk.
[Zakim]
DanC_jam, you wanted to relate product description example from OWL discussions
[PGrosso]
I completely don't understand what TBL is saying here.
[Ian]
TBL: When one defines a protocol standard, one defines a set of rules and an associated value "You get these invariants by following these rules."
[PGrosso]
I had no idea we were talking about defining a protocol. I thought we were defining how to provide context to some xml chunk. Not what context is interesting to an arbitrary process.
[Ian]
TBL: In this case, we are talking about defining a protocol where we are saying "If you use one of these chunks, you agree that this chunk makes sense whatever its ancestors are. But it does require namespaces and xml:lang to be inherited. And we commit to only using qnames in element and attribute names. Here are the benefits of sticking to this constrained usage of XML..."
[PGrosso]
I see no way for the XML Core group to know what context is of interest to a given app.
[Zakim]
timbl, you wanted to propose that long with a definition of a chunk, which may or may not (prob yes) have an xml:lang, one has rules about not using qnames except for element and attribute names
[PGrosso]
Unless we just send the entire document, we risk not including *some* context, and how do we know that context wasn't important to someone?
[Ian]
DV: Even if we took the xml fragment spec and ended up calculating equality on infoset terms, not sure the eq function would be useful. E.g., entities would be lost.
TBL: Right, you have you eliminate that: rule out use of entities or define equality as being "after dereferencing entities".
DV: This is not just an infoset comparison; you need more metadata than you find in the infoset spec.
RT: Difference is choosing in advance what's important (TBL's approach) v. specifying what's important at run-time.
RT: The agent makes the choice of which equality function to use.
TBL: Might be a machine...
RF: But machine is told by human....
TBL: we are seeing a common occurrence of the need to be able to put chunks of XML into an application.
[PGrosso]
If you want context-free XML, then you don't have to send any context. I remain confused. If you want xml:lang, that's context.
[timbl]
By being a less precise protocol, it gives you no value back.
[Ian]
[We look at http://norman.walsh.name/scratch/infoset-equal.txt]
[timbl]
PG: yes, you have it. Very little context.
[Ian]
NW: I was curious whether I could do what TBL was talking about. "infoset-equal.txt" is a quick attempt. Children you compare in order, attributes you have to compare as a set.
[timbl]
Good job, Norm.
[Ian]
ALH: See the DOM3 nodeEquals function.
[timbl]
positive energy ... people see solution ... all talk at once. Happy to lose audio channel clarity for increased group energy :-)
[DanC_jam]
mixed energy, I'd say.
[Ian]
MJ: How about stopping about providing guidelines for equality functions.
PC: I think it's extremely dangerous to define something as a base, then to use it to test equality of things on the Web.
[timbl]
PC, does your comment only apply to ordering?
[Ian]
PC: Fragments of XML are in the eye of the beholder. Dangerous to have just a default mechanism for chunk equivalence.
[Arnaud]
Here is the DOM 3 function: http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/core.html#Node3-isEqualNode
[Ian]
TBL: I hear PC expressing a concern that XML users will have this foisted upon them. But it should be clear that producers/consumers of this type of content only do so with prior agreement.
[DanC_jam]
(I think timbl underestimates the danger of premature standardization here. The W3C label is a dangerous doodad.)
[Ian]
TBL: E.g., I wouldn't expect XQuery to find two chunks equal.
[Norm]
If this existed, users would demand the XQuery/XPath function that performed it.
[Ian]
TBL: An XQuery processor might use this equality function if it knew it was dealing with chunks.
JM: I think we have a framework for doing this - infoset. We can add a language property to the infoset if that's the problem.
MR: Beware of retroactive changes to the infoset.
[timbl]
Sounds as though the infoset needs xml:lang added if used for this purpose, but will not also need other things removed?
[Norm]
xml:lang is already in the infoset, it's an attribute
[DanC_jam]
but there's isn't a property that relates a child to the parent's xml lang.
[Ian]
NW: We are citing xml:lang as an example.
[Zakim]
Norm, you wanted to say xml:lang is a special case.
[Ian]
NW: I think xml:lang is just one case. Adding an "inherited value" thing on xml:lang only is of limited value.
SW: How do we follow up on this topic?
[timbl]
Norm, there is a very finite set of things to inherit . xml:lang, xml:base too, but not an unending set.
[Norm]
What about xsl:version? What about 'lang' in DocBook, there is no finite set
[Ian]
DC: While this is something I want, I can wait for it.
[richard]
xml:base is already exposed as the [base uri] property
xml:space is another one that isn't exposed in that way
[Ian]
LQ: No clear conclusion for me. I think we've rat-holed a bit on equality. There are other things we haven't defined about two fragments (e..g, how you recognize two fragments as XML in the first place).
DV: I think a basic equality at the infoset level would not address more than, say, 15% of users. To hit the 80% mark, we'd need to add a lot more metadata.
[DanC_jam]
DC also said: I'm not quite sure who the customers are today.
[Ian]
MR: I've said my piece.
[Ian]
PG: I'm more confused now than when I came in.
ALH: The argument that it's not useful since not a big audience reminds me what we said about the infoset spec. The infoset solution we came up with is still useful, even if it is more meta. I think there would be a use for picking one basic equality function and then allowing people to extend the definition.
DL: I think chunks/fragments are important things. We have a lot of experience but no significant standard.
[PGrosso]
I see at least three issues here: equality, providing arbitrary context, and defining the "canonical context".
These are potentially orthogonal issues.
[DanC_jam]
good observation, PG.
[Ian]
DL: I think you probably can define a default equality. But good question is who are the customers.
[timbl]
If you don't define equality, you can't serialize it at all. because you don't know whether you have serialized it right.
[Ian]
JM: As far as I can tell, the customers are not for equality, but rather, RDF folks are using xml:Lang without inheritance in RDF context, and not recognizing inheritance quality in XML Chunk context. Unclear what need there is for canonical form, whether one is suitably powerful. I think it may be possible to meet customer demands without getting into the equality issue.
[Arnaud]
tim: I don't understand that, we don't define equality of documents, and still have a serialization for it, why would it be different for "chunks"?
[richard]
or, by defining a serialization, you implicitly define equality. that was what the original canonical xml as used in the test suite was for.
[timbl]
this is NOT a default!
[Ian]
PC: I'm convinced that it's dangerous to define a default comparison technique without providing users with a way to say "don't use the default."
[timbl]
this is NOT a default!
[Ian]
TBL: Nobody is suggesting this would be a default.
PC: I think that it would be used that way.
JM: In what sense is it not a default?
PC: If you define a basic equivalence function, you need an extension framework as well.
[DV]
I really wonder if we have requirement and usage feedback from DOM3 equal() function, are people happy ? Do they use it ?
[Ian]
SW: I see value in addressing the problem of propagating context in which a fragment of XML occurred.
MJ: I am in favor of a mechanism that uses infoset.
[PGrosso]
Actually, I didn't hear anyone talk about propagating context, but providing context.
[Norm]
I think it could be done. I can imagine that it might be useful. Dan made a parenthetical remark in IRC about the danger of stamping the W3C imprimatur on this functionality. If we had it, the XQuery/XPath functions and operators spec would have to define a function to do it. I worry that the conflict between "standard equality" and "the right equality operator for this application" would create confusion and introduce new problems. I don't know if they'd be larger or smaller than the problems we have now, without a "standard" equality function.
[Ian]
TBL: The user wants something simple but relatively context-free. People want something like exclusive canonicalization. But that spec doesn't have xml:base and xml:Lang. So there are invariants that don't work.
[Zakim]
timbl, you wanted to say that the problem may be simpler than many XML Core group eg PGrosso feel, as thy have been into very complex things. DV may underestimate the proportion of uses of XML which are really simple. I understand the danger of confusion between this (simplified) case and the general complex case, but feel that that should not stop one doing what was simple.
[Ian]
TBL: On DV's point, I think that you underestimate how useful this capability is.
[Norm]
xml:lang is just an attribute. xml:lang is just an attribute. xml:lang is just an attribute. xml:lang is just an attribute. xml:lang is just an attribute. :-)
[PGrosso]
When TBL speaks of context, I hear him just talking about propagating "inheritable" properties down to all elements. Is that all we're talking about?
[DV]
Maybe my 15% was an extreme estimate, maybe the DOM3 users can comment on usefulness of a basic function ...
[Ian]
TBL: This is a simple requirement; just allow people to define applications with minimal context.
[Norm]
Is this really about embedding XHTML in RDF?
[Ian]
JM: If this is a problem of serialization, the Core WG washed their hands of this years ago....We didn't find use cases outside of digital signatures. Unclear to me that the RDF WG has not chosen the right set of tools to meet its needs. I think that the infoset is the right tool (for taking content from one context to another). I don't think exclusive canonicalization is the right approach.
[DanC_jam]
DanC: (in reply to "we didn't find any customers"): maybe I [as XML activity lead at the time] didn't get on enough airplanes and find them.
[Norm]
It is demonstrably the wrong answer in that I can't store an xsl:template as an XML literal in a property value
[Ian]
TBL: But the RDF folks need to serialize as well to send across the wire. You need to know when you've correctly serialized.

3.2.2 Linking (xlinkScope-23)

Issue xlinkScope-23

[Ian]
LQ: There is a task force addressing linking. Six people, three from XML and Hypertext CGs. I am Chair. I asked each of the participants to sent a position paper and to review the documents. That was a month ago. We are early in the coordination process.
[LQ reviews the original issue]
LQ: We are still working in the Task Force on the problem statement.

3.2.3 XML Core WG comments on Webarch LC

[Ian]
PGrosso: several people read the document. No comments from readers that as a group we wanted to make.
TAG thanks the Core WG for their review.
[DanC_jam]
hear hear
[timbl]
TimBl echos his thanks to core for reviewing the doc
[Ian]
RF: Within the infoset, is a qname represented as a URI + name or a prefix + name?
DV: Depends on what context.
RT: It has all three. The ones that we regard as THE TRUE ONES are the namespace URI and the name. The prefix was primarily there for the benefit of pre-namespace APIs.
After the meeting, RT observed about these minutes, "RF also mentioned that it was for better round-tripping and I agreed."

3.3 XML Schema WG Liaison [2 March]

Present from the TAG: DanC, StuartWilliams, MarioJeckle, Norm Walsh, TBL (on phone), NoahM, RoyF, IanJ. Minutes by Mary Holstege.

Resolved that the record of this meeting will be public (no objections).

MSM: We are working on webarch comments.

  1. Qnames in content
  2. Abstract component references
  3. Versioning

3.3.1 QNames in content (qnameAsId-18)

See TAG finding "Using Qualified Names (QNames) as Identifiers in XML Content"

MSM: Those of us who have read it see nothing to object to. Weren't sure that differences from previous draft were, however.

NW: Old said no single way to define ways to mapping prefixes to namespace URIs. e.g. XML Namespaces way and XPointer way. New says that, plus, please don't invent new ways, prefer in-scope namespaces in the tree.

NM: XQuery way is to be deplored?

NW: Isn't XML, don't say anything about that. XQueryX would be different story.

3.3.2 Abstract component references (abstractComponentRefs-37)

http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2004Jan/0011.html

Apropos of http://lists.w3.org/Archives/Public/www-tag/2003Oct/att-0027/FindingabstractComponentRefs-37.html

MSM: XPointer schemes have (), we're leveraging XPointer, so what are we do do?

RF: Introducing balanced syntax in L-R parser. Blows up complexity. In XPath expressions independent of XPointer. But want to use identifier for component, far, far better off using name than expression (XPath) through XML trees.

HT: Assertion, not argument. Simplicity of no consequence for URLs that are many characters long and have lots of odd characters. Simple state syntax see no reason to be part of web arch.

RF: Not part of Webarch, but that wasn't question. Wasn't () originally, was ^ as escape character. Turned out that ^ was not in URI but in pre-URI, and would be escaped in actual URI.

DC: Most pressing use case is pointing at user-defined datatypes. First design that occurs to me is #sku. Why not?

MSM: Multiple top-level symbol spaces. #sku could be type, element, attribute, notation, attribute groups, named model groups...

DC: OK, so don't do #sku to do that. Advise users to not have two top-level things named the same.

HT: Equivalent to making IDs on everything you want to refer to.

[[MRys joins]]

HT: Can use it to identify components to reasonable degree of success.

DC: Suggest simple hello world earlier in SCD document.

HT: But this is intermediate, stop-gap. Doesn't meet requirement of being able to give a name to everything in your schema. Difference between application/xml and schema components.

DC: Can you use #sku to refer to user-defined type or not?

MSM: #sku points to element bearing ID in XML document. There is currently no normative statement of bare names in fragment identifiers in XML. Denotation would be the XML element bearing that id. To refer not to that element, but an abstract object, I may say "close enough" or I may say "nope, sometimes I want to talk about the element, sometimes the object".

NM: Reminding of relation between document form of schema and schema components. Even if have schema document, much of content of component pulled from other bits of markup, perhaps even in different file. Using markup as proxy for component is questionable.

DC: Considering different media type?

A: Yes, tied up with lhs issues.

MSM: Reiterates LHS issue. To define fragment identifier have to define MIME type, lhs has to refer to a schema. Feeling is that we concentrate on RHS and look at LHS another day.

HT: Opposite end of hello-world problem. Schema with elements in one namespace, types in another namespace, where other namespace is only named, no schema document specified (import namespace no schemaloc). Now want to refer to the type, perhaps anonymous, of element in some content model. May know what I want to refer to it, and how to refer to it in context of the schema, but don't know how to refer to "the schema". LHS needs more than one document to pin it down.

TBL: Get architecture nailed down right. Don't be frightened by time it takes to register MIME type. Leave philosophy aside for another day. Consider a fragment as referring to those well-defined things schema has: elements, types, etc. so others can refer to those from outside. Don't worry about XML level.

MSM: agree. Not really worried about time to register. Note we have thus far not seen need to have special MIME type and pleased with the leverage we've had with application/xml. Some resistance to defining special MIME type.

DC: Is OWL referring to user-defined datatypes just one of a long line? What are other use cases? Please make simple things simple.

HT: There are lots use cases, that is right up there at the top. General requirement that every component should have names. And top-level named types should have simple names.

DC: Just want named user-defined types. Don't need anything else.

HT: Believe MSM misunderstood TBL; believed TBL to say its OK to refer to components and don't think you have to go via XML representation.

NM: Another LHS example. N schema docs on command line, lax validation, no explicit imports. Finding media type that represents synthesis of that assemblage and point into that, whether or not ever transfer it.

DC: OWL not interested in any of that, willing to tie one arm behind back. To refer to one's _own_ user defined type. Not arbitrary things over which you have no control.

Q: Have we not been asked to provide general architecture for naming components?

PVB: Clarification. Simple OWL case, schema is only simple types?

DC: Now wondering about people wanting to point into schemas they don't control.

PVB: If one mechanism for that customer, and another for folks who want to point into more complex schema you don't have control over, is that OK?

DC: Yes.

Clarification: part of complexity is namespace binding. Director has said cannot get namespace binding via XML surrounding context.

DC: I expect people I represent would take this syntax. My taste would like it shorter.

Example in question: http://www.w3.org/XML/Group/2003/11/WD-xmlschema-ref-20031107/#example1 and the SCD is #xmlns(po=http://www.example.com/PO1)xscd(/simpleType(po:SKU))

DC: Asks for assessment of how long this is going to take?

MSM: We hope to speed it up; slower than we would have liked. "please make schema components first class objects" came from TBL conveyed by DC. From this I derive universality requirement. Clarification?

DC: There is a principle of making everything FCO. User requirement is really user-defined types.

TBL: If easy to refer to anything, would be great. Ideal would be schema worked that way as well. If URI is very long and complicated and you don't use it yourselves I wouldn't push for that. Putting IDs on it would be suboptimal but might be acceptable.

MRys: Use to have addressing mechanism to identify at least certain components. XQuery has notion of identifying local element declarations via schema component paths. Is one of most complex parts of XQuery. If making that even more complex, I fear usability in context of XQuery will turn people off. Before make any decisions in schema WG want thorough design review by XQuery etc. Clarification: fear about both current XQuery syntax, or SCDs.

DaveO: Drags us back to () comment.

DC: Roy clarified not derived from webarch, design preference about left-to-right parsing. Caret really breaks things, and people %-escape these so not really an issue.

NW: XPointer has ^ to escape literal ().

RF: Always preferable to allow user to assign names to things.

MSM summarizes take-homes: We have been talking about full and abbreviated syntax analogous to those in XPath. So take home is if can had naked identifier syntax as well, don't forget, that's OK, that's good.

There is a draft summary; not a TAG finding yet.

HT: We were concerned if this finding appeared to deprecate existing W3C rec without giving very detailed reasons for that. XPointer framework and element schemes are recs. Because of our intentions to use XPointer, and belief it serves us well, were concerned that finding not even appear to say "in hindsight XPointer was a mistake and shouldn't be used"

3.3.3 Versioning (xmlVersioning-41)

DaveO: TAG has published draft finding on extensibility and versioning. Lot of work and discussion in various forums. Finding nets out to saying: "gee, its hard; here are some 80-20 good practices". Number of recommendations in it. Previous version had a detailed description of a rather kludgy schema technique and was omitted from latest version. In Web Architecture it is my thesis that there is an implicit constraint that the web achieved loose coupling because specifications were built to allow versioning of various aspects, typically by providing extensibility and then must-ignore or should-ignore rules. People having difficulties with getting that with schemas. So now we want to liaise about right way going forward, what should we advise people going forward.

MSM apologizes for our lack of getting any kind of comments back on draft finding. Short description of what we hope to do in schema 1.1 besides some cleanup, the main technical area is supporting versioning. So area of great interest to us. One of most frequently observed problems is the pernicious effect of interaction of optionality of last named element, a final wildcard, and UPA (determinism) rule. We have not made a formal decision, but barring nasty surprises we strongly support "weak" wildcards that would ameliorate that problem. Other things we think need to be done to handle some common cases. But the weak wildcards appear to go a long way. Problem of getting 1.1 out in timely fashion. We have also started work on working paper of our own, which may make as a note, which will talk about versioning from our point of view. Immediate target audience is schema WG, but other folks interested in those technical problems also.

DaveO: One of things that seem to have been very useful in parts of web architecture as shown by HTML was notion that extensibility is passive in that language designer does not have to predict the future and think about where they add extension hooks. A schema 1.1. that supports default extensibility?

MSM: we don't have clear consensus on shape of answer for that. In scope, wouldn't rule it out.

PVB: Early on we had lot of discussion of that and chose explicitly to require active extensibility. It will behoove us to revisit that design point based on experience. We may come to same conclusion, may not.

(HT: posted references to prior discussion)

DaveO: Two paths forward. (a) schema WG do something in this area in 1.1 and (b) to not. Question to discuss. If schema 1.1 were to decide to do this, what does deployment timeline look like? 4-5 years from now? Looks like a long way away. So, are there other solutions? e.g. Could we say that model group errors are ignorable in WSDL? So when 1.1 comes along they could flip the bit.

NM: Delighted to see TAG taking interest in versioning. cf: http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Oct/0019.html But I am worried about going wrong by taking a simplistic answer. Schema-based solutions tend to say "person describing vocabulary makes the decisions" SOAP says "sender says it in the instance". No cosmically correct one answer. Would also say that there seems to be implicit assumption (via HTML) that data in a particular format has a particular processing model so you can say universally what "must ignore" means. Example of PO, where old version had no country code and new one does. Don't want to decline to accept order, or store in DB (where I _do_ store the CC so it isn't ignoring), but the applet that calls the guy, it is really important that I stop and not dial that guy. Where do you put the hooks? One answer might be N schemas. Also a lot of questions about who has what schemas. Somewhere original schema. Somewhere an extended, new version of schema. Can consumer of data pull new schema? Some say OK, some say that cannot be. Lots of dimensions. Think they're hard. Haven't seen simple 80-20 point.

Clarification: "must ignore" is too simplistic, either in instance or the vase schema.

NM: Don't believe there is no cosmically one right answer. Just suggesting that it is complex. Need 80-20, but let's make sure we're really hitting the 80 and look at all the cases first.

TBL: Noah is right that it is tricky to do this without dealing with semantics of the application language. Hard in schema because it doesn't know that. Seems to be this conflict between either putting in this wildcard or just having a completely strict schema. Proglangs export through named interfaces. e.g. here is a foo, and here's some things about it, but doesn't stop others from defining something that matches that foo. Look at new schema and whole thing falls together and validate. Application semantics that go ahead with being that foo, left to application.

HT: Problem with passive extensibility is that if you push it too far you get to place that only a completely toothless schema would get you what DaveO is talking about. So, why have a schema. Now looking at whether looking at partial validity results in PSVI take you closer to where you want on intermediate position. I'm somewhat skeptical, but work to be done.

DE: My constituency is very afraid of what will happen with second version of our schemas. That we don't have a good story is painful. Seem to have been talking about planning for extensions, not planning for versions. Versions are about labelling the extensions. Seems like we have a labelling issue there also.

DaveO: Thing WSDL is looking at is how do you identify these versions? How do you talk about old and new, even though compatible with same namespace? Agree. What is right way to do version identifiers?

MRys: (1) XML is often used in late-validated way. May have lots of schema that describe one form of semantics or other of the document. Don't see problem of requiring users to use new schema for same target namespace that is more appropriate for that context. (2) Have to distinguish between versioning and extension mechanisms. Have extension mechanisms. Shouldn't add additional functionality before existing mechanisms are adopted in marketplace. Many seem unaware of what exists. Add lot more stuff in 1.1, people will give up on XSD entirely. (2) Versioning should be done at different level. Partially as guidelines, e.g. revving URI, revving URI only if breaking existing constraints. Should think about a separate abstraction level that deals with versioning. Leave it to domain-specific processing model to deal with it. Not schema 1.1 which is too disruptive to tools out there.

MSM: wrt passive extensibility. Believe one reason we haven't had consensus for it is because it isn't enough. I as vocabulary designer had resisted notion of global gang switch open/closed. Wanted finer control. OTOH have now come to view that global switch would be handy. Some idea similar to QT of core syntax and extended syntax that compiles down to core syntax might do it. Need to be designed carefully. WRT TBL's lament about something between wildcards and total strictness, that's what substitution groups do. For many cases that works just as you wish. Doesn't work in some use cases, because you have to get schema document that has the elements that can substitute and that is undesirable/not possible in those cases. Finally, believe that having completely toothless schema isn't necessarily worthless. If foo in version 1 has a, b, and c (of types ta, tb, tc), I could make that relatively toothless by making things choices optional and wildcards, but instance with a, b, c will still have type annotations of interest in PSVI.

PD: Really important issue, esp. wrt web services. TAG finding mirrored our (WSDL) view on versioning. Versioning is generic issue, not just schema issue. Could be best practice or arch finding. Something missing from TAG document: description of multiple versions and how they relate with each other. Need clear way to say that. Imagine it might be done in another specialist vocabulary. Tools just aren't there. Tools say schema says document valid or fails. We must communicate that HTML got it right, that must-ignore by default was right, and constraining things is harmful.

DaveO: Default extensibility as automatable transformation to throw in wildcards in various places. Requiring a tool be run over a schema to get extensibility lops off 90% of the people. So pushing back on that.

MSM: Clarification was that it wouldn't be a user-visible step, but part of language.

DaveO: Really glad to see that these issues looked at so seriously by schema WG. Hope our (TAG and my) work has been helpful in moving work along. Look forward to seeing schema wg ongoing interactions with TAG. Willing to help out in whatever role in this area.

MSM: Thank you all.

3.4 Voice WG Liaison [4 March]

Present from the TAG: Ian Jacobs, Chris Lilley, Stuart Williams. Minutes by Max Froumentin.

  1. Error Handling
  2. Information Space vs. application space
  3. Navigation
  4. Mixed Markup

Resolved that the record of this meeting will be public (no objections).

SW: Tag Arch Document is in Last Call. We want to talk also about TAG issue mime-type-override recovery from error, and mixed markup.

Brad Porter reviewed the Arch Doc and summarized his comments.

Brad Porter: Differences in the voice Web:

Dan Burnett: "your interaction has to keep going"

Raman: in the voice experience, you can't stop. A consequence is that the dialogue has to continue, unlike with a screen.

BP: a large part of the processing is error handling: what if the user doesn't say anything, etc. How do you fallback and continue the dialog

Kuansan Wan: are we talking about telephony or also voice interaction in cars for example? where the car maker would have added a push-to-talk button and voice isn't the only way to interact with the system.

Jim Barnett: errors aren't errors in the real sense: they're just natural behavior, more approximation than error.

BP: re. Kuansan's question, the discussion here is considering the worst case scenario (i.e. voice only)

3.4.1 Error Handling (errorHandling-20)

BP: in VoiceXML we let the content author handle the error, as opposed to the 'browser'

From section 1.2.3 of Arch Doc: "User agents that correct errors without the consent of the user are not acting on the user's behalf"

Comment from Brad Porter: separation between content author specifying error handling and agent handling an error

3.4.1 "User agents should detect such inconsistencies but should not resolve them without involving the user."

Comment from Brad Porter: Reference "error" handling (1.2.3)

"User agents MUST NOT silently ignore authoritative server metadata."

Comment from Brad Porter: Is the concept of "server" core to the web architecture? Shouldn't this be protocol, message, etc? Need to define "server metadata", "protocol" in glossary.

SW, IJ: This will be fixed as we incorporate text from the recently approved TAG finding "Authoritative Metadata" back into the Arch Doc as clarification.

IJ: we just approved a new version of this metadata finding where we eliminated the concept of server.

SW: metadata about the message and the representation

TVR: re handling errors, newer specs such has xforms where you can put error handler messages inside user controls. Client can handle pretty complex error conditions handled on the client and specified by the markup user

IJ: in the TAG we've discussed what is an error. e.g. is 404 an error? TAG thinks not necessarily, it's a protocol state. there are things that are planned for, and situations that need redressing but that aren't errors. The mime type override was a case of a spec taking control over another. Are there other places in vxml?

BP: if you don't have a text-to-speech engine available, is that an error? From our perspective, there are no errors. Everything should be accounted for intrinsic error will involve hanging up on the user

IJ: are there places in your spec where you have errors?

Scott McGlashan: yes, but they are all recoverable. The language provide a mechanism for handling them within the language itself

TVR: we do far more error handling on the voice side, i.e. content author's side

SMG: all the burden is on the author, which is perhaps different from traditional approach

SW: the mime-type mismatch is one kind of error, and it must be fixed, and somehow it has to be notified to someone. Inconsistency is not to be ignored but propagated to cause back pressure to the system

SMG: we now generate an error and it's the markup author to fix it. We still apply the same principle

SW: we're satisfied with how the mime-type issue was handled.

BP: main objection we had was user-agent interaction with user.

IJ: can you identify any part of the spec where there is some overlap with some other protocol?

SMG: in VXML 5.2.6 pre-defined events relate all to errors, dealing with http responses. e.g. HTTP 404. The author is given control on intercepting events

SW: is author the author of a grammar or of the page that uses it?

SMG: VoiceXML document author. Typically you have VXML document and SRGS document and they would be written by the same org.

IJ: looking at 5.2.6, one of the events is no input. User Agent Authoring Guidelines have things to say about that. Users needing additional time

SMG: can be tuned by user agent. Question is how the user has an impact on UA settings

DB: because there is no chrome, there isn't a way for the user to request things except with the user agent.

TVR: WAI guidelines on timeout is also an usability question. User experience would be a lot worse if the UA waited a long while.

JL: author could write routine to ask user how long they're ready to wait. Author decides if they want to use it or not.

IJ: does VXML talk about guidelines for app authors mentioning accessibility issues as well as architectural issues.

SMG: vxml spec doesn't have guidelines. We decided so after talking to WAI groups

Jim Larson: we haven't had recent contact with WAI

Emily Candell: guidelines are a good idea but they are a risk for application authors if done wrong

DB: application authors can always write horrible code. Establishing behaviors that apply across all applications is very tricky for voice apps.

Debbie Dahl: we could start out with some WAI guidelines and then explore usability experience

SMG: WAI would say "every type of voice input must have a dtmf equivalent": very difficult for directory enquiries for instance.

IJ: I was editor of UAAG and I'm happy to talk to this group how they would apply them to your case

TVR: let's not blindly apply guidelines to voice interaction

BP: moving on... another special think is that user doesn't know they're interacting with voicexml. Everything transparent.

3.4.2 Information Space vs. application space

"Web architecture includes the definition of the information space in terms of identification and representation of its contents, and of the protocols that support the interaction of agents in an information system making use of the space."

Comment from Brad Porter: Fundamental tension between information space and application space.

SW: comment is going to charge us to rearticulate this sentence. Other groups have reacted to it too. REST (from Fielding) describes a hypermedia system, and give a sense that there's an information space below. That's the penny-dropping distinction.

From 3.5.1 "It is a breakdown of the Web architecture if agents cannot use URIs to reconstruct a "paper trail" of transactions"

Comment from Brad Porter: URI's identify resources not transactions; fundamental difference between safe and unsafe. URIs really only effectively account for safe transactions. Transactional meta-data identifies the participant in the transaction, the transaction target, the required value modification, and the session in the case of incremental updates. Should a URI really incorporate all of that?

IJ: I have an action item to rewrite this section. We were trying to describe a POST interaction where the resulting URI would be bookmarkable. Distinct from saying that all transactions can be encapsulated in a URI

Chris Lilley: we're saying: if you've made a new resource, give it a URI

BP: my question was should you have access to the result or should you be able to reconstruct the history to get to that resource

3.4.3 Navigation

Comment from Brad Porter: The requirements of navigation (forward/backward) of an information space through a user agent, bookmarking within that space, and user-agent addressing in that space expose limitations in the basic URI system. The basic caching constructs don't work. Version information is in the content (such as in W3C documents) not in the fundamental addressing structure of the web. Human-readable requirements on URIs make using checksums difficult. Are URIs meant to be human readable?

BP: At what level of granularity are we trying to give user control. Is there a unified concept of "go back" across all modalities, or is it dependent of the media and modality. We don't have bookmarks in our voice systems. But if you add bookmarks, you break the system if you want to bookmark latest-version vs. explicit-version. I wonder if there's work going on in the TAG about versioning navigation

SW: there's work going on in the TAG regarding that domain. different keywords.

IJ: does the VBWG think bookmarking in voice space useful?

SMG: there is no chrome, no browser, to which you could add bookmark. Again it's at the application layer

CL: uris being readable is not a TAG arch requirement. In voice application your client is on the server, you can't switch applications, ...

[Summary: there's no chrome with VoiceXML]

IJ: at the app layer, there would be guidelines that apply, one way to read the guidelines is to substitute agent with voice application. Read it that way, are there any problems?

BP: being freed from concepts of chrome (bookmarks, etc) you will want to generalize concepts such as go-back, navigate. URIs wouldn't be a good mechanism to define this, e.g. bookmarking the current-version when you're in an explicit version

IJ: the application designer needs to take that into account

BP: but how do you infer that automatically. Or where is the metadata if you use it?

TVR: safe vs. unsafe voice interactions

IJ: idempotent/writable interactions make sense in the voice context?

TVR: if the URI is truly idempotent, doesn't encode data time (e.g. weather forecast page), then it's useful to bookmark, anything else isn't

BP: go-back in voice doesn't follow from a URI history would like followup conversation on that.

DB: SSML tries not to have errors...

TVR: note that the differences we're observing here with respect to navigation and URIs is a consequence of the granularity of transactions in voice interaction being more fine-grained. In other words, these problems exist on the visual web but do not show up as early as they do in voice interaction. Or to treat anything as error keep rendering even if it's not like the author intended I don't know how that fits with arch doc

CL: ArchDoc requires you to document the error handling strategy. Aslong as the strategy you mentioned is documented, its ok.

3.4.4 Mixed Markup (mixedUIXMLNamespace-33

SMG: in v3 (our next-generation dialogue language) we are striving for better interaction with other languages one consequence is that we'll be producing modules. Looking for answers how to do that.

CL: have to work out what inserting some v3 into xhtml means, also semantics of tree traversal. What the combination means is there is no general strategy.

SMG: will make it hard to us.

CL: doesn't mean there's nothing you can do. One other way is : "do not assume you're the root node"

SMG: additionally we have notions of states

JB: we could define what other things do when plug into v3. voicexml could also plug in to other things, need to define that.

Philipp Hoschka: I worked on modularization of SMIL. we say that if you plug SMIL in a host language, then that's what happens.

SMG: that's what we're looking to do.

TVR: we've talked about this with XHTML/SVG/HTML, where rendering semantics prevail, but what happens when you plug input technology, events... One visual piece (e.g. SVG) might need to react to the input happening makes the design interesting and complicated

CL: agree, we do that in SVG

TVR: we started off with html as documents, then got this idea that the document is in the interface. Now we're talking as applications as documents.

BP: good news is that the webarch does work for us. Interesting to go forward keeping this dialogue going keep it tightly synchronized is key

IJ, SMG, and BP discussed the Voice WG sending "stories" to the TAG for the Arch Doc involving voice interactions.

3.5 I18N WG Liaison [4 March]

Minutes are available in the I18N WG mailing list. TAG participants were Chris Lilley and Stuart Williams. As of 23 March 2004, the minutes from the joint meeting were very sparse.

3.6 Web Services Description WG Liaison [4 March]

Minutes not available as of 23 March 2004

4. Follow-up on Internationalization Issues

The TAG does not expect to discuss the topics below this line.

5. Status report on these findings

See also TAG findings

6. Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/03/27 15:04:36 $