Skip to content
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

Closed
tmichel07 opened this issue Oct 3, 2017 · 5 comments
Closed

Abandon use of XML. #446

tmichel07 opened this issue Oct 3, 2017 · 5 comments

Comments

@tmichel07
Copy link
Contributor

tmichel07 commented Oct 3, 2017

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.

@skynavga skynavga changed the title [ttml2] TTML2 wide review comment: styling Abandon use of XML. Oct 3, 2017
@skynavga
Copy link
Collaborator

skynavga commented Oct 3, 2017

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".

@tmichel07
Copy link
Contributor Author

tmichel07 commented Oct 3, 2017 via email

@skynavga skynavga added this to the Editor's CR Work List milestone Oct 3, 2017
@skynavga skynavga reopened this Oct 3, 2017
@skynavga skynavga removed this from the Editor's CR Work List milestone Oct 3, 2017
@nigelmegitt
Copy link
Contributor

@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?

@skynavga skynavga added agenda and removed agenda labels Jan 8, 2018
@css-meeting-bot
Copy link
Member

The Working Group just discussed Abandon use of XML. #446, and agreed to the following resolutions:

  • RESOLUTION: No change will be made here.
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.

@dwsinger
Copy link

dwsinger commented Jan 9, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants