-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abandon use of XML. #446
Comments
The comment is that XML should be abandoned for some unknown, not yet defined syntax. With all due respect, this is not a practical suggestion in the context of TTML, which has a well established usage and community of use. The WG may wish to discuss further, but I see no other resolution than "works for me". |
Glenn,
Same here...
I don't think this type of issue should be closed without at least
responding to the commenter and try to collect his approval.
thierry
Le 03/10/2017 à 20:44, Glenn Adams a écrit :
… Closed #446 <#446>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#446 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AGiYfgxfFKuOpr7bm97T4ldpDzy6YT-Oks5sooCqgaJpZM4PrqVC>.
|
@dwsinger Just to clarify, does this issue relate to the representation of the infoset in the specification document, or the recommended concrete encoding in Appendix A? |
The Working Group just discussed
The full IRC log of that discussion<nigel> Topic: Abandon use of XML. #446<nigel> github: https://github.com//issues/446 <nigel> Glenn: I propose as Works For Me. <nigel> David: It doesn't work but I think we'll have to close it as is because it's too late to change. <atai2> q+ <nigel> .. I recognise that changing the basis of TTML at this stage is not practical. <nigel> ack atai <nigel> Andreas: There's a huge discussion about XML on the web and it has been abandoned there. <nigel> .. There are two reasons for that - draconian error handling and namespaces. I don't agree <nigel> .. on them, but they can be worked on. For error handling, we are adopting a looser and <nigel> .. more flexible way to handle errors, which is good and in line with HTML. I think namespaces <nigel> .. are really a problem and I'd like a version of TTML without any namespaces. <nigel> .. This issue should be taken with us for our specifications because it is an important <nigel> .. issue for moving TTML to the web. We should be reasonable and think about handling <nigel> .. namespaces and if we decide tomorrow to keep existing vocabulary in the same namespace <nigel> .. then it is a good start and partly addresses David's issue. <nigel> Glenn: Can we mark it as WG-Rejected. <nigel> Glenn: Can we mark it as WG-Rejected. s/./? <nigel> s|Glenn: Can we mark it as WG-Rejected. s/./?|| <nigel> s/./? <nigel> s/WG-Rejected/WR-Rejected <nigel> RESOLUTION: No change will be made here. |
I agree that the design basis of TTML cannot be changed now. However, I think that the continuing issues with moving things between namespaces, and with being conformant to old and revised versions of namespaces, and so on, needs examining in the W3C (possibly by the TAG). |
Comment sent by David Singer singer@apple.com
Date: Sat, 30 Sep 2017 17:47:23 -0700
https://lists.w3.org/Archives/Public/public-tt/2017Oct/0000.html
TTML is based in XML, but experience over the years has shown that the ‘X’ (extensible) is deeply problematic.
When a specification is revised, either all the new features are in a new namespace, which makes documents messy and hard to read, or they have to fit into places where ‘any’ element or ‘any’ attribute is allowed in the prior grammar. Unfortunately, the latter leaves the new elements/attributes very much in a second-class-citizen state. If instead, a new namespace and grammar is minted, then the documents are no longer recognizable to and processable by a reader written to recognize the old namespace ID, even if the extensions and new elements can be ignored and fallback behavior is acceptable.
When the incorporation of elements designed by other bodies is included, the result can be a bewildering mess. This has sometimes led to attempts to ‘make native’ these elements, and effectively copy their specification from the external definition into the revision; but this raises questions of attribution and backwards compatibility.
I recommend the group consider a re-design using a more flexible and less problematic base syntax.
David Singer
Manager, Software Standards, Apple Inc.
The text was updated successfully, but these errors were encountered: