- 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:45 UTC