W3C中国

W3C正式启动数据标准计划(Data Activity)

2013年12月11日,W3C发布了新的数据标准计划(Data Activity),致力于将Web的数据互操作能力推向一个新的水平。目前,该标准计划包括两个新设置的工作组:

- Web上的CSV格式数据工作组(CSV on the Web Working Group):为依赖数据的Web应用在处理CSV(逗号分隔的数值)格式或其他类似格式的数据集时,提供高层的互操作能力。

- Web数据最佳实践工作组(Data on the Web Best Practices Working Group, DWBP):其任务是(1)开发开放数据生态系统,在开发者和数据发布者之间建立更好的交流沟通平台;(2) 为数据发布者提供指南,指导他们提升数据管理过程中的一致性(consistency),提升数据的可重用性;(3) 采用各种技术建立开发者对数据的信任度,提升数据应用创新的巨大空间。

W3C的数据标准计划(Data Activity)是在原有语义Web(Semantic Web)和电子政务(eGovernent)两个标准计划的基础上合并整合而成的。W3C仍将继续增强语义Web的标准化工作,满足现实世界对语义Web技术的不断增长的需求。

更多信息,请参阅新设立的数据标准计划(Data Activity)。 更多关于W3C标准技术领域和标准计划的信息,请参阅W3C的标准计划页。参阅该消息的英文摘要

W3C新任命技术和社会(T&S)及信息与知识(INK)两个领域的技术负责人

2013年11月11日,W3C正式宣布,将原来技术与社会标准技术领域(Technology and Society Technical Domain, T&S)拆分为技术与社会技术领域信息与知识(Information and Knowledge Technical Domain, INK)两个技术领域,并任命了这两个新的技术领域的标准工作负责人。

 

Wendy Seltzer将担任W3C技术与社会(Technical and Society)领域的技术负责人(Domain Lead),重点推进Web的隐私保护、安全,以及未来与社会化Web、数字营销(Digital Marketing)等相关的标准工作。同时,Wendy仍继续承担原来W3C在法务和政策方面的工作。
 

Ralph Swick将担任W3C信息与知识(Information and Knowledge)领域的技术负责人,重点推进Web数据、语义Web技术、数字出版,以及XML相关的标准化工作。Ralph仍同时兼任W3C的首席运营官(Chief Operating Officer, COO)职务。

更多关于W3C的标准计划,请参阅W3C的标准计划(W3C Activities)页。更多关于W3C管理团队的信息,请参阅W3C Management Team页。查看本消息的英文摘要,请参阅这里。 

wendy

 

ralph 

W3C发布性能时间基线(Performance Timeline)和用户定时(User Timing)的正式推荐标准

2013年12月12日,W3C的Web性能工作组(Web Performance Working Group)发布了两份正式推荐标准。查看英文摘要

- 性能时间基线(Performance Timeline):该规范定义了一个统一的接口,保存和获取性能相关的度量数据(metric data)。该规范并不覆盖单独的性能指标访问接口。
- 用户定时(User Timing):该规范定义了一个接口,帮助Web开发者通过访问高精度的时间戳(high precision timestamps,精确度量其应用程序的性能。

更多信息,请参阅W3C的富Web客户端标准计划(Rich Web Clients Activity)
查看W3C的所有正式W3C推荐标准(W3C Recommendations),请参阅W3C正式推荐标准列表

欢迎志愿者参与W3C标准翻译计划,提供W3C标准规范的志愿者翻译和W3C授权翻译。 

W3C发布进度事件(Progress Events)的提案推荐标准

2013年12月12日,W3C的Web应用工作组(WebApps Working Groups)发布了进度事件(Progress Events)的提案推荐标准(Proposed Recommendation)。该规范定义了一个用于度量某一任务(如HTTP的Body部分的传输)进展程度的事件接口。该规范可以为其他W3C规范提供关于进度描述的支持。欢迎您于2014年1月17日前提交对该提案推荐标准的意见和建议。

更多信息,请参阅W3C的富Web客户端标准计划(Rich Web Clients Activity)
提案推荐标准是W3C标准制定流程的一个环节,指标准的技术性和可实现性已经经过广泛的审查和验证,W3C正式将标准文本提交给W3C顾问委员会作最后批准。经过批准后,W3C将发布正式的推荐标准(REC)。查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档

W3C发布XSL转换(XSLT)3.0版标准草案最终征求意见稿

2013年12月12日,W3C的XSLT工作组发布了XSL转换 3.0版(XSL Transformation, XSLT 3.0)的标准草案最终征求意见稿(Last Call Working Draft)。该规范定义了XSLT 3.0的语法和语义。XSLT是一个XML文档格式转换的语言,定义从一个XML文档格式转换到另一个XML文档格式的转换规则。XSLT语言的转换采用良构的XML格式的样式单(Stylesheet)方式定义。欢迎您于2014年2月10日前提交对该标准草案的意见和建议。

更多信息,请参阅W3C的可扩展标记语言标准计划(Extensible Markup Language/XML Activity)。 查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。  

W3C发布DOM解析和序列化的标准草案最终征求意见稿

2013年12月10日,W3C的Web应用工作组(Web Applications Working Group)发布了文档对象模型解析和序列化(DOM Parsing and Serialization)的标准草案最终征求意见稿(Last Call Working Draft)。该规范定义了各种API,允许Web应用通过编程方式访问HTML及通用的XML的解析器,对DOM节点(DOM nodes)进行解析和序列化。欢迎您于2014年1月7日前提出您对该标准草案的意见和建议。 

更多相关信息,请参阅该消息的英文摘要,及W3C的富Web客户端标准计划(Rich Web Clients Activity)。 

W3C发布跨源资源共享的提案推荐标准 向公众征求意见

2013年12月5日,W3C的Web应用工作组(Web Applications Working Group)Web应用安全工作组(Web AppSec)联合发布了跨源资源共享(Cross-Origin Resource Sharing)的提案推荐标准(Proposed Recommendation)。该标准定义了在必须访问跨域资源时,浏览器与服务端应该如何沟通,它提供一种机制,允许客户端(如浏览器)对非源站点的资源发出访问请求。所有提供跨源资源请求的API都可以使用本规范中定义的算法。
 

处于安全性的考虑,用户代理(如浏览器)通常拒绝跨站的访问请求,但这会限制运行在用户代理的Web应用通过Ajax或者其他机制从另一个站点访问资源、获取数据。跨源资源共享(CORS)扩充了这个模型,通过使用自定义的HTTP响应头部(HTTP Response Header),通知浏览器资源可能被哪些跨源站点以何种HTTP方法获得。例如,浏览器在访问 http://example.com 站点的Web应用时,Web应用如果需要跨站访问另一站点的资源 http://hello-world.example,就需要使用该标准。http://hello-world.example 在HTTP的响应头部中定义 Access-Control-Allow-Origin: http://example.org,通知浏览器允许 http://example.org 跨源从 http://hello-world.example上获取资源。


欢迎您在2014 年1月14日前提出对于该标准的意见和建议。关于跨源资源共享的更多信息,请参阅 CORS W3C Wiki。更多信息请参考W3C的安全标准计划(Security Acitivity)富Web客户端标准计划(Rich Web Client Activity)。我们非常期待听到您的意见。

提案推荐标准是W3C标准制定流程的一个环节,指标准的技术性和可实现性已经经过广泛的审查和验证,W3C正式将标准文本提交给W3C顾问委员会作最后批准。经过批准后,W3C将发布正式的推荐标准(REC)。查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。   

W3C发布CSS Shapes的标准草案最终征求意见稿

12月3日,W3C的级联样式单(CSS)工作组发布了CSS形状(CSS Shapes Module Level 1)的标准草案最终征求意见稿(Last Call Working Draft)。CSS Shapes允许开发者用CSS定义一个几何形状,在Level 1中,CSS Shapes可以,定义非矩形的形状,提供围绕指定形状的浮动布局(floats)能力。一般的盒模型(Box)允许内容围绕给定的矩形区域布局,而一个圆形形状的浮动布局,将使内容环绕所定义的圆形形状区域布局。CSS欢迎您于2014年1月7日提交对该标准草案的意见和建议。

更多信息,请参阅W3C的样式标准计划(Style Activity)。 

查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。  

W3C发布High Resolution Time的标准草案最终征求意见稿

12月3日,W3C的Web性能工作组(Web Performance Working Group)发布了高解析度时间(High Resolution Time Level 2)的标准草案最终征求意见稿(Last Call Working Draft)。该规范定义了一个JavaScript接口,为Web应用提供亚毫秒级(sub-millisecond)解析度的当前时间信息格式。此类信息可以用于应用程序的性能调试或时间同步。欢迎您于2014年1月8日前提交您对该标准草案的意见和建议。

更多信息,请参阅W3C的富客户端标准计划(Rich Web Clients Activity)。 

查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。   

GB/T 15834-2011 Part 5: Positioning of Punctuation Mark

GB/T 15834—2011出版物上数字的用法(General Rules for Writing numberals in Public Text

本文部分翻译了国标GB/T 15834-2011中关于标点符号位置的内容。该国标的中文全文,可以在互联网上找到。


5. Positioning of Punctuation Mark.

5.1 Positioning of Punctuation Mark in Horizontal Writing Mode

5.1.1 Full stops(U+3002), commas(U+FF0C), ideographic commas(U+3001), semicolons(U+FF1B), colons(U+FF1A) should all be after the corresponding text, and carry one em space. They should be placed in the lower left corner, and could not be the start of a line.

5.1.2 Question marks(U+FF1F), exclamation marks(U+FF01) should all be after the corresponding text, and carry one em space. They should be placed in the left side, and could not be the start of a line. When two question marks(or exclamation marks) are used together, they should only carry one em space; when three question marks(or exclamation marks) are used together, they should only carry two em space; when one question mark and exclamation mark are used together, they should only carry one em space.

5.1.3 Left quotation marks(U+2018, U+201C), left brackets(U+FF08, U+3014, U+3010), left double angle brackets(U+300A), and left angle brackets(U+3008) should be placed on the left side of the relative characters and could not be the end of a line, while right quotation marks(U+2019, U+201D), right brackets(U+FF09, U+3015, U+3011), right double angle brackets(U+300B), and left angle brackets(U+3009) should be placed on the right side of the relative characters and could not be the start of a line. Each of these marks should carry one em space.

5.1.4 A double dash(U+2014) is between the two corresponding words, and carry two em space. It should be aligned to the vertical center of the corresponding base character, could not be separated into 2 parts nor to be the start and the end of a line at the same time(原文是“不能中间断开分处上行之末和下行之首”). 

5.1.5 A double ellipsis(U+2026) should carry two em space. When 2 double ellipsis are used together, they should carry 4 em space and make a independent line. A double ellipsis could not be separated into 2 parts nor to be the start and the end of a line at the same time.

5.1.6 The en dash of hyphens(U+2013) is a little shorter than the Chinese character "one" and should carry half an em space; the dash of the hyphens(U+2010) is a little longer than the Chinese character "one" and should carry one em space; the wave dash(U+301C) of the hyphens should carry one em space. All of the hyphens should be aligned to the vertical center of the corresponding base character and should not be the start of a line.

5.1.7 Interpuncts(U+00B7) are between the two corresponding words and carry half an em space. They should be aligned to the vertical center of the corresponding base character and should not be the start of a line.

5.1.8 Emphasis dots and proper marks(underline) should be underneath the characters.

5.1.9 Slash marks(U+002F) carry half an em space and could not be the start not the end of a line.

5.1.10 When a punctuation mark is at the end of the line, to beautify the whole composition, even if it's a full-width character, it should carry the same em space of a half-width character.

5.1.11 In the practice of composition, for a better composition or reading experience, or to avoid the line-breaking of the last character of a bottom paragraph or a new page cause by the last character(which will result in a wasteful and ugly layout), we could reasonably reduce the space of the punctuation mark.

5.2 Positioning of Punctuation Mark in Vertical Writing Mode

5.2.1 Full stops(U+FE12), commas(U+FE10), question marks(U+FE16), exclamation marks(U+FE15), ideographic commas(U+FE11), semicolons(U+FE14), colons(U+FE13) should all be placed in right corner under the corresponding text.

5.2.2 Double dashs(U+2014), double ellipsis(U+2026), interpuncts(U+00B7), slash marks(U+002F) and hyphens should be placed in the middle under the corresponding text, in a vertical writing mode;

5.2.3 Quotation marks(U+FE41, U+FE42, U+FE43, U+FE44) and brackets(U+FE35, U+FE36, U+FE37, U+FE38, U+FE39, U+3A) should be up or down the corresponding text.

5.2.4 Presentation form for vertical wavy low lines(U+FE34) should be on the left side of the the corresponding text.

5.2.5 Sesame dots(U+FE51) should be on the right side while the presentation form for vertical low lines(U+FE33) should be on the left side of the corresponding text.

5.2.6 The rules about whether a certain punctuation mark could be the start or the end of a line in Horizontal Writing Mode are also required in Vertical Writing Mode.

此外,还有相关的GB/T 15835—2011
5.1.7 Line-breaking
An Arabic number in Chinese should stay in one line and never be broken.

[1] CJK标点符号 http://www.unicode.org/charts/PDF/U3000.pdf
[2] 中文竖排标点 http://www.unicode.org/charts/PDF/UFE10.pdf
[3] CJK兼容符号(竖排变体、下划线、顿号)http://www.unicode.org/charts/PDF/UFE30.pdf

感谢Xiaoqian Wu提供翻译文字。

W3C发布Web MIDI API的标准工作草案

W3C的音频工作组(Audio Working Group)于11月26日发布了Web MIDI API的标准工作草案(Working Draft)。该规范定义了支持MIDI协议的API,Web客户端应用可以通过该接口枚举和选择MIDI的输入和输出设备,以及发送和接受 MIDI消息。通过提供底层接入,该API可以使音乐和非音乐MIDI应用访问MIDI设备。Web MIDI API不定义音乐和控制输入的语义,它主要定义MIDI输入和输出接口结构,以及如何发送和接收MIDI消息,而不必识别这些消息/动作的具体含义。 Web MIDI API通常与其它web平台的API和元素联合使用,如Web Audio API。其它系统的MIDI API用户,如Apple CoreMIDI和微软Windows MIDI API用户,将来也应熟悉此API。
 

更多信息请参考W3C的富Web客户端标准计划(Rich Web Client Activity)

站内搜索

万维网联盟(World Wide Web Consortium, W3C)是Web领域的国际标准化组织,致力开发开放Web标准确保Web的长期发展,实现“尽展Web无限潜能”的使命。

更多内容>>

近期活动

更多内容>>

W3Cx 开放课程

W3C技术标准

查看Web技术标准
- 所有标准
■ Web与产业融合 ■
- 汽车 | 数字出版 | Web与电信
- 娱乐与广播电视 | Web支付 | Web数据
- 物联万维网(WoT) | Web安全
■ Web For All ■
- Web无障碍 | 国际化 | 索引(A to Z)
■ 社区组与商务组 ■
- 所有社区组 | 新建社区组
■ 标准工作组 ■
- 所有标准小组 | 参与指南

更多内容>>

W3C标准翻译

欢迎您加入W3C翻译计划,了解W3C标准和文档翻译情况,帮助提供不同语言的W3C标准规范及文档的志愿者翻译及W3C授权翻译,惠及全球技术社区。

更多内容>>

贡献榜

我们通过贡献榜,感谢您积极参与W3C的标准制定及审阅工作、提供标准及技术文章的中文翻译、参与各类技术研讨会。

更多内容>>

W3C 中文开发者社区

W3C中国目前正在不断加大全球W3C工作的参与力度,并推动了一系列以了解中国行业需求、引导标准制定为主要目的的工作组(WG)、兴趣组(IG)和社区组(CG)。
Web中文兴趣组 | MiniApps工作组 | MiniApps生态社区组 | 弹幕特别任务组 | 中国信息无障碍社区组 | 中文数字出版社区组 | 数据可视化社区组 | 中文文字布局需求特别任务组

更多内容>>

会员链接

相关资源需要使用 W3C账号登录后使用

首页 | 加入工作组 | 申请W3C账号 | 最新会员消息

开发者资源

合作伙伴

  • 北京航空航天大学
  • 北航计算机学院
  • w3ctech