See also: IRC log
shawnm: The subset is safe, reg exp that match the subset will be as how to refer to character ranges. These ranges end on chars which are unassigned. You could put a codepoint into the reg ex, there are no escape sequences. On the tested engines that's fine but you are putting an unassigned code-point into the exp. This is unprincipled for the standard and would like strange in ITS spec.
… in the spec maybe refer to it with XML values
daveL: Any comments?
… did you say there was another update to do on that shawn?
shawnm: not complete yet but will send this week
daveL: action on text for unicode norm. Action 430.
shawnm: not done yet, still pending.
… will have reg ex done by wednesday call not action 430
daveL: Appreciate that
daveL: Action 434 were you able to get any further on this Christian?
chriLi: Will start working on this tomorrow
daveL: Appreciate this
daveL: Action 435 tadej asks for this to be postponed until wednesday in his absence. (only on IRC)
… Christian do you have time to talk to Tadej and Milan about this?
chrLi: Yes, on wednesday
daveL: things that weren't captured on actions. There are a number of things there relating to best practices. He was asking christian if that would help with the NIF converstion / normalisation. AFAIK: Felix has not had time to discuss NIF with Sebastian Hellman. Christian, have you replied to that already?
… you'd had a comment on canonical XML and interchange formats.
… Felix was asking what that topic would address normalisation issues to do with NIF converstion.
chriLi: I would need to revisit Felix's comments to answer that
daveL: maybe worth waiting to see what we get from Shawn in a day or 2
… felix likely out of action this week.
… seems like a big topic
We'll leave that for now
chriLi: I will look into this in the meantime
<daveL> deferred until wednesday
daveL: a couple of issues for discussions, raised by felix
… between co-chairs issues have been divided up so we focus on different things and assure tracker is kept up to date.
… we have an xhtml test which addreses this but querying whether it should be there or not
Yves_ when you xml lang in html5 this is allowed but it has to have the same value as lang and can only be there if lang exists as well. Dont think we need to test for that we just look for lang value and see if its the same as xml lang. -ve test shows invalid HTML5 test.
… for XHTML the xml lang value takes precedence. Problem is we didnt say we were processing XHTML therefore if this is required should be a different test.
shawnm: Should not have a third mode. XHTML should be processed as XML or as HTML hoping for markup. There is perhaps an ambig over lang or xml lang taking precidence.
Yves_ XHTML file using validator.nu raises issues. If I try to process the files as an XML doc then then both notations are required.
shawnm: XHTML would raise bigger issues using XML markup?
Yves_: only problem is the XML Lang attribute.
… I guess we can work around this but worry about others, using other parsers.
daveL: Anyone else have concerns about this? Share shawns broad view as not testing against XHTML.
Yves_: Do we have a should keyword in the documentation?
… yes we do
daveL: a general should - is not generally tested for. We havent to date but we dont have many of them
shawnm: An interesting should "quotes txt" it is perfectly acceptable to have an XML only tool within the ITS spec. Following should in section 7 makes doc that is not processable by XML only validator.
Yves_: tricky as file is processable by two different validaotrs with different expectations.
shawnm: is it acceptable to use both notations?
Yves_: Maybe its fine the way it is and that we dont test for it, just provide guidelines.
daveL: could that should be converted to a best-practice?
shawnm: Would feel more comfortable about this being a best practice
Yves_: good arg for both
shawnm: Lang - correct behaviour - xhtml = lang attribute, in xml = only xml lang, it takes precidence
Yves_: remove the example from the XML test case as there is no need for it there
… still not resolved general xml issue but we should not have an XHTML example there
shawnm: I agree with you
<scribe> ACTION: leroy to remove XHTML example for ITS language information [recorded in http://www.w3.org/2013/02/04-mlw-lt-minutes.html#action01]
<trackbot> Created ACTION-441 - Remove XHTML example for ITS language information [on Leroy Finn - due 2013-02-11].
Yves_: How we test XHTML is a different topic, right?
daveL: Yes, should raise as a general topic
<scribe> ACTION: daveL to raise an issue on how to test for XHTML [recorded in http://www.w3.org/2013/02/04-mlw-lt-minutes.html#action02]
<trackbot> Created ACTION-442 - Raise an issue on how to test for XHTML [on David Lewis - due 2013-02-11].
daveL: Will raise the issue, Yves, can you respond to that?
Yves_: yes, of course
Yves_: SVG can be in XHTML and Jirka raise an issue that XML cannot be validated in the svg snippet
… was an argument from Jirka shown above.
shawnm: no way to put local attributes on svg etc.
Yves_: So its a non-case
shawnm: theoretically yes
… if its important to you as doc author to use local markup on embedded svg then use HTML
daveL: Comment from mauricio on that topic
mauricio: the most important thing is that these decisions effect the impl
implementations we're doing for WP 3
… I think that we will address that after the contents have been translated.
mauricio: A formal way to show what they have done, best practices not fully supported.
… I'd like to know a better way to do this
… Can I use XHTML like XML with global rules and locally with XML format?
daveL: In your case (section 7) it should be used like HTML. In your case is that HTML for public consumption?
mauricio: The content is extracted from the CMS, translated and sent back
daveL: its HTML that is publicly shown.
mauricio: Drupal extracts that
<Yves_> I think in Linguaserve case the XHTML is not for Web broswer so using the XML notation for everything is the way to go.
<kfritsche> the XHTML is only a interchange format, drupal shows it as HTML5
daveL: Section which says should is for public consumption, which is not the case in your case.
… Still seems to be an open issue
… need input from Jirka on SVG and other vocabs within HTML
… should we put this is as clairification in the spec?
mauricio: some guidelines would be very appreciated.
daveL: Agree these are big classes of applications
daveL: Add a note about SVG and MathML re treating XHTML as HTML
… implication on best-practice and on the test suite
Yves_: Its a should so should be clairifed in the section. 2 test cases, one for XML notation and one for XHTML notation. Allowing the user to choose.
daveL: So have examples in section 5
… Yves would you be willing to draft some text on that
Yves_: Yes, will do if you raise an issue on that
daveL: One thing, shepherds for various issues… Can you look back and see if people have responded. If not, after a week please email again stating if you dont hear back within a week it implies you are satisfied
… would ask others to follow up in this way
… that way we have a record that we did our best for clarification
daveL: meeting closed. Talk on Wednesday