See also: (incomplete) IRC log
-> http://www.ltg.ed.ac.uk/~ht/DPD_2009/talk.html ht's slides
<ht> http://www.w3.org/QA/2009/11/default_prefix_declaration.html
-> http://www.w3.org/QA/2009/11/default_prefix_declaration.html blog entry
dpd file has the mapping to prefixes
slide 6 shows different ways to find the right dpd
order in the slide would be order used to find it
<johnk> can you in-line DPD prefix mappings?
<Zakim> timbl, you wanted to comment on the evils od defaults and search paths .. failure scenarios
TimBL: we should investigate
... I'm keen of the idea of linking to the mime type
... one technical issue =
<ericP> timbl: defaults are worrying
<ericP> +1
TimBL: I worry about when somebody writes something assuming a namespace
... when you havea language than imports things
... using URIs is "this is what I mean"
... if I rely on the default, that's a technical issue
<Zakim> johnk, you wanted to ask about inline DPD mappings
Johnk: can I just inline mappings in the (html) document
<timbl> If I rely on a default ns decl and someone else pasted in some code which overrides the prefix then my code breaks. search path hell.
ht: no, it's precisely what the proposal tries NOT to do :)
<ericP> timbl, i think that "using html" works well in rigorous namespace environments
Doug: you can't use xhtml in IE
<ericP> it gives you nice defaults with very little text if you want to be lazy, but full rigor when you have complex docs
ht: this proposal is NOT going to work with legacy software
Noah: mostly I like this
<Zakim> noahm, you wanted to ask about the concern raised by Liam in his 28 Nov comment on the TAG blog entry, I.e. that An earlier version of my proposal did use prefixes; I found,
<noahm> http://www.w3.org/QA/2009/11/default_prefix_declaration.html
Noah: in Liam's comment on Nov 28
... maybe the answer is ht's answer "not for legacy browsers"
ht: yes
... firefox will complain it's not xml
... that's a weakness
<Zakim> shepazu, you wanted to ask why we need a level of indirection, why not simply declare default prefixes?
Doug: you're changing xml ns declaration by equal declarations somewhere
... problem in html5 is that there's a disconnect between declaration and content
<noahm> I think Henry's proposal mostly deals with copy/paste, because the DPD bindings have document scope and are consistent throughout
Doug: if you cut/paste a fragment that is mathML, the ns decl is not copied with it
ht: it is intended to address that
<noahm> If you copy paste mathml from one part to another, the bindings >should< be the same, because the came from e.g. the media type or perhaps a document-scope link to a dpd.
ht: everybody would use ml:.... for mathML
... and the default decl would be linked to the mime type
Doug: I see
<Bert> (Seems to me the problem is that there are too many obscure namespace URLs around. Why not use a single one, http://w3.org/ns, for all our specs? Everybody can remember that.)
<Zakim> masinter, you wanted to point out that we're trying to design something such that polyglot documents (those that mean the same whether text/html or application/xhtml+xml) can use
<DanC_> Doug: is there a need for flexible prefix bindings?
<DanC_> Ivan: the RDFa use cases
<noahm> LM: I think it's to promote polyglot
LarryM: this is calling for a change in html and xml
... I'm asking for a clarification
ht: 2 ways to read this wrt xml
<noahm> Noah says: I think it's more than polyglot. It's to provide a useful, tractable middle ground, giving some of the benefits of decentralized evolution to those who >only< use HTML 5 serializations.
ht: xml will use ns only if there are bindings to uris
<Ralph> [better reason why non-hardcoded prefixes are desirable is that some mix-in vocabularies, such as RDFa, want to be able to use the same binding mechanism as the underlying markup language rather than having separate binding mechanisms]
<shepazu> [I wonder if this applies to root elements as well as ns prefixes... for example <html><body>...<svg>...</svg></body></html>]
Ivan: I look at the whole thing from the RDFa POV
... the approach is attractive
<DanC_> HT suggested the possibility of reading the XML NS spec as compatible with this proposal. I don't accept that reading, since existing conforming software will reject the example in HT's write-up.
Ivan: but an additional mechanism to add a namespace declaration anywhere in the document is nice
<noahm> I reluctantly agree with Dan on compatibility with existing XML NS
ht: interesting, maybe someone else can help with this
... the proposal is to avoid writing ns decl
... for people who don't want to write them and still use polyglot documents
... it does not conflict with MS' proposal
Ivan: if I have something locally that is not using xml ns decl, an API will swallow what you have here
<Zakim> timbl, you wanted to discuss clipboard types and to discuss clipboard types: When an editor being used is awarethat it is editing XML or editing HTML, then pasteboard
TimBL: on the question of cut/paste, an editor can deal with that
... sender and receiver can negotiate what you send/receive
... so software can negotiate conditions
<DanC_> (anybody know how much flexibility there is in clipboard implementation? are those 10-years-old and never-to-change? or are 3 webkit hackers working on it next month? is MikeSmith here?)
TimBL: what you can do when you cut/paste between amaya or firefox to an email, the necessary info could be copied with the fragment
<DanC_> ericp, google docs is a pretty popular HTML editor. and the various js blog editing widgets.
TimBL: the code would be aware of that it is xml
<noahm> The clipboard impls I know about, specifically Windows, are old, but the set of formats are extensible, and it's up to the sending and receiving apps to negotiate. I.e. sender offers one or more, receiver chooses what it wants. So, mostly extensible.
<DanC_> right, so it's a question of the apps, noah.
<noahm> Yup.
<ht> I heard Ivan suggest something which would allow local reference to something like a DPD, so that an RDFa fragment could carry its NS bindings with it
TimBL: if you paste to a generic xml application, pieces of declaration would be added
<noahm> Regarding what Tim's saying, I think the likely answer is: sender and receiver have what they need to do this, but might need to each take the trouble.
<Liam> [if everyone used xml-aware or html-aware editors there woudl be no need for syntax changes]
<DanC_> [really Liam? I think quite a few people are using these js-based HTML editing tools, and that's exactly where the API issues with namespaces arise.]
<timbl> To do a proper cut and paste between XML documents now you shuld do a transfer of a full-qualified fragment anyway.
<Zakim> noahm, you wanted to clarify that it's for more than polyglot, I think
Noah: I heard polyglot is legal xhtml served as text/html
... I don't think this proposal is for this case
... this proposal would be a step to a polyglot
<DanC_> distributes extensibility? the extensibility here is centralized, i.e. via the text/html media type registration DPD document or whatever.
<johnk> DanC, yes
ht: I used polyglot in ordinary language
... we need a different word for compound doc
... I meant multiple ns doc
<Zakim> Thomas, you wanted to note that "copy & paste" is the equivalent of dealing with namespaces in canonical xml, and boy is that a headache
<tlr> "hybrid"
tlr: copy/pasting fragments with critical information is a source of major headache in C14n
<DanC_> (what's the ACL of the record of this meeting? can we use this record a part of the (public) proceedings of the TAG?)
<masinter> (hope so)
tlr: it's much easier said than done
<timbl> That is true, Thomas, that specifically CURIES make this much more difficult.
<tlr> curies and qnames
<noahm> Dan, we were told when I asked at a start that this was a public discussion and that we could use this IRC log as a source for our public TAG minutes. I'll assume that unless told otherwise.
<DanC_> oh... timbl meant CURIEs where he wrote cries
TimBL: that depends on the xml. when you have qnamesand att values, you need to handle that properly
<tlr> qnames in content, when implementors cry ;-)
<Zakim> johnk, you wanted to note that it is not just "editor" software that has this problem
<ht> HST thinks of SOAP
JohnK: the cut/paste problem is not restricted to human-used software
... we have this problem and there's no stdization around that
TimBL: C14n and xmlsig
... and in the RDF spec
<ht> HST thinks cut-and-paste is one important use case, but not the only one by a long chalk. . .
<noahm> I agree with HST. The important use case is enabling distributed extensibility, with a sufficiently convenient syntax, and in a way that is to a significant degree compatible with the obivous XML serialization
<timbl> Liam: XML fragments have nothing to do with namespaces
Ivan: what you call a dpd defined in the xml format
... people want e.g. JSON
<timbl> Henry, the DOM has been the site of much of the angst around namespaces in HTML5 -- in your proposal, di we assume thet the prefixes would all be worked our in hte parser and the reesult be equivalent to that of a normal XMLHTML document?
<DanC_> (hmm... I thought the leaning in the RDFa community was to put something DPD-like _inside_ the content document)
Carine: how do you handle conflicting prefixes from the doc writer and e.g. the MIME type
ht: the proposal has the order of priority
<ivan> to DanC_: both. Yes, there is something they call @prefix which is similar, but there are also discussions exactly in the same direction than these, ie, having also binding defined externally
Noah: it only happens in XML serialization?
ht: if I use rel=... and the media type says something else
... priority/conflict resolution similar to CSS
TimBL: ns attributes will magically appear in the DOM (from the parsing) ?
ht: yes
... in my view the difficulties of dealing with the DOM when there are namespaces are exaggerated
<DanC_> ok; good to know, ivan
<timbl> http://www.centralprefixregister.com/
<ivan> DanC_: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Dec/0034.html is just an example that came in this week
<noahm> I think the way to look at this proposal is: the HTML5 spec already provides full namespace support in the DOM for the XML serialization; with this proposal, some of that capability will become available using the text/html serialization
-> http://www.barefootliam.org/xml/20091111-unobtrusive-namespaces
Liam: I wanted something that works in legacy browsers
[The rest of the discussion will be rescheduled, Liam's phone line is
Carine: Other item to discuss will be sticky namespaces, see http://www.w3.org/QA/2009/11/default_prefix_declaration.html#c184989
LarryM: it's important to focus on a single consistent proposal
<DanC_> (how is this about logistics? I guess he meant tactics)
LarryM: the initial question of what do we need to do, who do we need to convince
<masinter> let's focus on creating a single proposal that everyone who wants namespace support in HTML, and to do so quickly
<masinter> To impact HTML5, getting a proposal in *before* the HTML5 last call would make sense
<DanC_> I've been using TagSoupIntegration-54
<DanC_> http://www.w3.org/2001/tag/group/track/issues/54
<Liam> [note, tag needs to consider also the ISO proposal, DSRL]
<masinter> focus on taking the things that are "options" are TBD, and drive the group to decide which way to go on them
<DanC_> "needs"?
<masinter> I think organizationally it is more appropriate for xmlnames to drive this issue with TAG help rather than vice versa
<DanC_> this #xmlnames channel was made up for the purpose of this 1-time ad-hoc meeting
<DanC_> there's an XML Core WG
Adjourned