TAG at TPAC 2008

SKW: I asked chairs whether there was interest to meet with TAG members during the TPAC...
... I won't be there.
... I've seen 2 responses:
... WebApps WG on the topic of URI Schemes for Widgets
... WAI-PF invitation to observe

NM: I'm likely to be availble to meet with WebApps
... there will be a room for a TAG meeting?

SKW: yes, there's meeting space reserved for TAG
... ok... so it looks like there's interest from TAG members to meet with WebApps re URI schemes

URNsAndRegistries-50

SKW: The OASIS XRI TC is asking whether their present direction is something the TAG thinks is promising.

NM: an important point is: these =xyz things... they aren't expected to be recognized out of context, but treated as a relative URI, and the XRI-related policy stuff would be communicated in the usual top-down ways

TBL: do they still expect to use this [?] in OpenID?

HT: I expect so, as that's a major use case.
... yes, this looks promising, but the devil will be in the details...

<noah> Right. What I said was: I would find it unacceptable if anyone proposed that the =xxx syntax was supposed to be recognized as an XRI in an arbitrary URI [context]; what I think is being proposed, and what's OK with me, is that URI http://example.com/=XRISyntaxHere is recognized as an XRI if and only if example.com says that they have used their URI space in this way.

HT: the XML base rules are specified in some detail by specs from the XML Core WG, and unless this proposal plays by those rules exactly, we'll have to discuss it in detail

HT: after 2 years of [writer's block], I think I'm on to something...
... earlier drafts would neither (a) convert a skeptic, nor (b) serve as an introduction to a someone new to the issue. It only spoke to those who already agreed.
... this approach is perhaps not effective enough to convert those who take an extreme view, but I think it's not as off-putting as earlier drafts
... is this a promising direction?

DC: I had a "I don't see point X covered yet" feeling, though I can't recall what the X was

AM: [oops; missed the question]

HT: I'm particularly happy with the list under "So, here are the requirements in detail"
... it doesn't yet incorporate a uri-in-uri requirement... I haven't gotten my head around that

TBL: perhaps in a break I can help with that

HT: there's a bit of "apples and oranges" between 'delegation' and the sorts of stability...

HT: the 1 / 1 / 1 extreme is, e.g. "the web". ownership is distributed, etc.
... the hypothesis is "we can do all 8 rows with http". That's what I'm working through.

TBL: a weakness in this table is that it assumes ownership, but naming schemes like using sha-1 don't really have ownership

DC: yes, I think we need an appendix to say "we're not treating the things that don't involve ownership"
... I've seen "the TAG thinks all new URI schemes are harmful" but I want to be clear that we're not going that far... only "no new schemes when there's an administrative hierarchy in place"
... counterexamples include freenode/p2p, sha-1, etc.

NM: I'm not sure the W3C example is a good one for the 0/0/0 case
... the W3C has delegation internally

HTML and Web: the Big Picture

SKW: I'm bi-modal about this topic. I understand that it is a high priority for the TAG and why. However, there are now communities with such established momentum in [many] directions that I wonder what impact the TAG could expect to have. In addition, my day-job focus is not on hypertext which means that finding time to commit to doing a proper review of a 450+ page spec. is a real challenge - it's not my style to skim read. In 3-5 years time, what advice does the W3C expect to be giving hypertext content creators - what recommendation will it be making? I think that the W3C presenting multiple options does not help content creators and amounts to "...let the market figure it out...".

DO: the way the HTML 5 spec is being produced... I have concerns about the process... but process issues are awkward for the TAG to address...
... meanwhile, it interferes with technical input, e.g. w.r.t. distributed extensibility

NM: perhaps nothing novel to add, but...
... we should give what technical input we think will help, and if our input isn't taken up, such is life
... if HTML and XHTML co-exist, the TAG should help W3C tell people when to use one and when to use the other and such
... that advice might include recommending practical approaches despite conflict with architectural principles
... one view is "there's clean XHTML and messy tag soup". Then I've ready comments on the HTML 5 spec about the way it mixes a spec for browsers with a language spec...
... perhaps you could write a clean language spec for HTML 5 and separate that from the browser-patch-up stuff. I don't hear much about that approach

HT: again, perhaps not novel... I'd like to help get the good stuff in HTML 5 more visible
... perhaps using traditional formal techniques and separate it from error recovery and such
... I see some support for this approach
... To the extent the TAG can do that, I'm interest.
... meanwhile, as a researcher, I'm interested in being more formal about the error recovery stuff.

DC: well, I was hugely frustrated with making no progress toward my goals for HTML 5 in the first year of the HTML WG, but a few months later, perhaps one year is not that much in the HTML timeframe. So I'm open to looking at lots of approaches

AM: I'm new to this area... the WHATWG is new on my radar. Looking at the landscape, I wonder if the chances of having impact are so low that... well... should we use our time for other things?

JAR: it looks somewhat daunting to have impact; most of my work is disjoint with this technical area

TVR: there's a potential crisis for the W3C if we say "HTML 5 is so difficult to deal with that we'll ignore it" then much of the work in W3C becomes irrelevant to deployment on the Web

<jar> scribe: jar

Around the table regarding html5

<timbl> Concern over - Losses of engineering quality, and architectural principles, which have serious consequences; - Changes of philosophy about improving the web as opposed to letting it fester while describing it; - Socially, lack of review by other groups who can't read the huge spec; - Socially and engineering .. making willful departure from other specs without negotiation with the other community.

timbl: people have accused of partisanship

stuart: Putting our analysis on record is a good idea.
... Let's document TAG opinion even if it risks having no effect.

noah: Important for TAG to approach sympathetically needs of the different communities. Core intuition - we need to document what the browsers do - is beneficial
... But to mix this with a language spec is not a service to the community
... Better if the document could be relayered. Separate permissive behavior from 'clean' behavior
... having a clean spec is good for content creators

ht: It would be good for goals of html5wg AND for w3c if a traditional language spec were separated out from monolithic
... and if it were described formally (with a grammar)
... (2) two bits of bridge-building to pursue: look at media type namespace defaulting proposal; and
... we need to find mechanisms, perhaps the w3c validator, perhaps via changes to specs, that help to people see that there are incremental improvements possible in the quality of their html documents

<noah> Actually, where I'm scribed as saying "separate permissive behavior from clean behavior" isn't quite the nuance I had in mind. I think a language specification indicates which documents are legal, and what they mean. That's one spec. I think HTML 5 as drafted also includes a specification for pieces of code we might call browsers, which by the way attempt to provide useful output for content that would not be "legal" in the language spec, e.g. improperly nested elements. I think having both
specifications is very important, but I would prefer that the browser
specification, including fixup of bad content, was separate from the
specification of the clean language and its correct interpretation. The
former spec. would be for authors and for those who might in future be
able to deploy less permissive UAs; the latter would be to achieve
interoperability among browsers as we know them.

raman: From TAG perspective, we must ask: How does the rest of W3C's work fit in with HTML5?

<Zakim> raman, you wanted to add treat html5+js as the assembly language of the Web, compile better languages to the assembly language for delivery. That is what everyone is doing right

noah: Consider possibility of encouraging people who can contribute to this discussion to run for an elected TAG spot?

HTML5 should be modularized?

noah: Different axes along which to modularize

ashok: There's a fairly large section on microformats - that should go in an appendix

danc: Does parsing html5 require parsing numbers?
... So what about document.write ?

ht: XML spec defines (BNF) which simultaneously defines language including entity refs AND language after entity ref expansion
... so to define two grammars is not completely unprecedented

noah: would be nice to define a correspondence between nicely formed input and the DOM

<DanC> (I think the spec for how markup relates to the DOM is currently specified as serialization rather than parsing in the current HTML5 draft)

noah: defining the DOM should be straightforward... then the script runs. Suppose new text is not nicely formed.
Maybe the specification for the clean
language can just not specify what happens in the intermediate states
while new text is being written, until the document character string is
once again properly formed. ?
... try to make it as declarative as possible

raman: Let's define clean version separately from conversion from not-clean to clean.
... Effect of executing document.write: apply same rules that would apply to get you from not-clean to clean
... html 5 spec is not clear on this. complicated state table
... browsers can load script synchronously or asynchronously (example of two .js files executing asynchronously)
... this twist is an accident. people noticed that the first script blocks the second script, workaround is document.createElement of a script tag

stuart: Remember Douglas Crockford article against document.write ?

ht: If you want a walled community, here's what the walls look like

raman: google ajax has no document.write. no namespace pollution
... you do your library as a javascript library. publish a 2nd file that's a load hook. defines one new name. there is no document.write or createElement. read the ajax documentation

timbl: About document.write: the createElement alternative is a pain ...

<bubbles> show source on the first one, and note the call to google.load()

timbl: but there's an ecmascript extension that makes it more concise

ht: it makes xml a first-class syntactic object in javascript
... The languages that permit xml elements embedded, have never taken off.

raman: Once you say declarative, all the imperative people come out and say you can't do everything declaratively
... but in Lisp, no one ever said "declarative". Instead they just made special forms that abstracted out the imperative part

timbl: Are there languages where SQL is integrated well into another language? [looking for precedent]

noah: (about xaml)

raman: document.write is a challenge to modularization. can we do: [core], error recovery, document.write ?
... document.write is what connects all the other clumps together

noah: Language spec says what tags, attributes means. A spec for a processor talks about what can be done incrementally, what is accepted. Error recovery is about not-legal input, here's how to process it.
... Language to DOM could be specified declaratively. It's not a processing problem
... Wants one module that says: This is the clean spec, here's what you should author to
... then error recovery would go in another module

danc: HTML 5 is not coordinating with other w3c activities. How should this be addressed. [looking at agenda - css, other web languages, ...]

break.

URI Parsing in HTML5

reconvening

danc: Why should I be worried about this?

raman: HTML5 spec has no business talking about how URLs are parsed
... should not be talking about how these particular strings should be interpreted. Rationale for doing so was error recovery...
... but this doesn't warrant defining the parsing rules for URLs.

noah: It says it's not using "URI" as defined in rfc3986. Maybe a better way to write it would be to give a new name for the syntactic change/extension to URI?

raman: Goes back to what group owns which specs

ht: XML Core has names for things like this. System Identifier is a nonescaped URI, vintage 1998. What you put into an XML doc that gets turned into a URI by a specified process
... 5 specs have this same problem - what to call things that get turned into URIs. They all cut & paste text that was written for Xlink 1.0
... When IRI came along, this became untenable. Current revision of IRI spec will include a section on 'legacy extended IRIs'
... Not clear when new RFC is coming out. hostage to IDN
... A part of HTML 5's problem has been solved by LEIRIs
... The problem is error recovery - what to do when the string isn't a URI
... First bullet (2.5.2 of [what document??]) is addressed by the WG note [on LEIRIs]

noah: First issue is stripping leading and trailing space ... no one is saying the spaces are part of the URI

ht: Principle of least surprise says we'd be better if across the board users had a single expectation on how to write URIs in the documents
... Ergo, (1) we need the RFC specifying URIs; and (2) we need to say how to write them in documents

stuart: Jena handles IRIs - has 6 modes of operation

ht: XML Core is trying to reduce this to 1

raman: URL situation is an example of the social problem. I don't expect to solve this, or if we do, for our solution to make any difference
... Rather, how do we bring about solution to social problem, of who owns what specs?

<DanC> SKW: "It is possible for xml:base attributes to be present even in HTML fragments, as such attributes can be added dynamically using script. (Such scripts would not be conforming, however, as xml:base attributes are not allowed in HTML documents.)"

[NEW]ACTION: Noah work with Dave to draft comments on exi w.r.t. evaluation and efficiency [NEW]ACTION: Stuart encourage discussion of proposal around http://xri.net/ or http://boeing.com.xri.net or http://xri/ or http://boeing.com.xri/ in www-tag [NEW]ACTION: Stuart to collect input from TimBL and others and revise issue description [NEW]ACTION: Stuart to schedule more discussion of exi architecture charset/encoding etc.