- From: Robert Leif <rleif@rleif.com>
- Date: Thu, 24 Nov 2011 11:53:57 -0800
- To: <liam@w3.org>, <tantek@cs.stanford.edu>
- Cc: "'Jeni Tennison'" <jeni@jenitennison.com>, <www-xml-schema-comments@w3.org>, "'HTML Data Task Force WG'" <public-html-data-tf@w3.org>, "'RDFa WG'" <public-rdfa-wg@w3.org>, <public-html-xml@w3.org>
- Message-ID: <089a01ccaae2$cdf6b4d0$69e41e70$@rleif.com>
Liam et al. I suggest that a time schema be created for the XML version of HTML5. This schema should include duration and other relevant data-types. The present incapacity of standard HTML5 to be extended by the use of schemas is a significant deterrent to its use with present XML data. I do not believe that it wise to attempt to interfere with HTML5 use in its present form or retard its becoming a standard. Its designers appear to desire flexibility and a relaxed syntax. I believe activities to include external schemas should be directed to the XML version, XHTML5. The description of XHTML5 is limited in the document, HTML5, A vocabulary and associated APIs for HTML and XHTML, Editor's Draft 04 November 2011 “1.6 HTML vs XHTML This section is non-normative. The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5 of the XHTML syntax, known as "XHTML5". The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in the XHTML syntax. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XHTML syntaxes.” I looked at Section 9 The XHTML syntax “Note: This section only describes the rules for XML resources” Unfortunately, I did not see how the html elements could interact with new elements that are derived from external xml schemas. Also there does not appear to be any mention of an xhtml5 schema. Fortunately, oXygen has made one available and provided assistance in its use. Presently, an XML version would require the use of schemas, which are not part of the standard. The problem of the addition of new data-types that can use the capabilities of the existing HTML5 data-types has not been solved. The simple test xhtml5 document below cannot be validated when I use a data-type (Bounded_16_Type) which is derived from a simple external schema (strings_bd.xsd) that contains a form. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html> <?xml-model href="file:/C:/Program%20Files%20(x86)/Oxygen%20XML%20Editor%2013/frameworks /xhtml/xhtml5%20(epub3)/epub-xhtml-30.rnc" type="application/relax-ng-compact-syntax"?> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" xmlns:strings_bd="http://www.cytometryml.org/ACS/strings_bd"> <head> <meta content="application/xhtml+xml" http-equiv="content-type" /> <meta charset="utf-8" /> <link href="html5_example.css" rel="stylesheet" type="text/css" /> <title>HTML5_Form 1</title> </head> <body> <form method="post" action="string_bd16.xml" enctype="text/plain"> <div class="entry"> <label for="form-1">Name</label> <input id="form-1" placeholder="Your Name" name="string_bd16" type="text" /> <!-- Use of type="strings_bd:Bounded_16_Type" results in: System ID: D:\XHTML&HTML5\Forms\XHTML_Form_Minimal_Bob_rnc.html Main validation file: D:\XHTML&HTML5\Forms\XHTML_Form_Minimal_Bob_rnc.html Schema: C:\Program Files (x86)\Oxygen XML Editor 13\frameworks\xhtml\xhtml5 (epub3)\epub-xhtml-30.rnc Engine name: Jing Severity: error Description: value of attribute "type" is invalid; must be equal to "email", "password", "search", "tel", "text" or "url" Start location: 18:11 End location: 18:39. Removal of <?xml version="1.0" encoding="UTF-8"?> did not solve the problem. --> </div> <!-- entry end --> <div class="button"> <button type="submit">Send</button> </div> </form> </body> </html> I suggest that the description of xhtml5 be a supplement to the HTML5 standard. I would also, if possible use, xsd1.1 as the basis for any schemas that need to be created. -----Original Message----- From: Liam R E Quin [mailto:liam@w3.org] Sent: Tuesday, November 22, 2011 6:13 AM To: tantek@cs.stanford.edu Cc: Jeni Tennison; www-xml-schema-comments@w3.org; HTML Data Task Force WG; RDFa WG; public-html-xml@w3.org Subject: Re: <time> values in HTML5 On Mon, 2011-11-21 at 16:46 +0000, Tantek Çelik wrote: > [..] > I'd suggest that for the purposes of transcoding to existing > type/value systems (eg XML Schema 1.1) that the new values: > > 1. Be treated as a simple string > 2. Provide input to the next iteration of such existing type systems > (eg XML Schema 1.2). Thus I would not hold back or modify any (even > imminent) CR drafts. I wouldn't hold your breath for a W3C XML Schema 1.2 in the next 5 to 10 years... for sure the current WG isn't chartered to do that work. > > BTW as a point of W3C process, I don't think it's permissible to add > new features to a CR without first going back to a last call that > includes those new features. XSD already has date/time types; sometimes an increase in interoperability (here by specifying an additional mapping from a lexical form, probbably) is worth while even at CR. Preserving timezones would be harder, since currently XSD times are historical (or extensionally defined), not intensional - there's no way in XSD to represent "the third Tuesday of the month" for exampel, or "8am local time, varying in UTC depending on the status of daylight savings time" for example. I think adding intensional time would be a significant change, and Mike Kay's idea of a separate document makes sense there. Adding a mapping from the "time" values to existing XSD types/values might not be a big deal, which is what I was thinking of, although if they're not stable I agree that it's not the time. I was originally hoping that e.g. an RFC822 timestamp would be supported, as that's a stable, well-documented and widely used format for timestamps and seemed sensible for use in HTML (the ISO style is obviously better for i18n but we already have that). Liam -- Liam Quin - XML Activity Lead, W3C, <http://www.w3.org/People/Quin/> http://www.w3.org/People/Quin/ Pictures from old books: <http://fromoldbooks.org/> http://fromoldbooks.org/
Received on Thursday, 24 November 2011 19:54:46 UTC