RE: <time> values in HTML5

Noah et al.

I totally agree with "Traditionally, XSD Recommendations have taken (all too
many) years to hatch, and introduction of new types has been tied to such
big releases." 

What you described is the old waterfall method of design. Standards like
many other software projects should be developed by Barry Boehm’s  Spiral
Model of the software process1. One starts small, tests the design and code,
and then extends the material in steps. A very good example of this is the
DICOM, Digital Imaging and Communications in Medicine, standard
(http://medical.nema.org/). It has been developed in separate volumes
(modules). It also has supplements. A small part of the standard can be
created, extended, or improved and subsequently published without changing
the content of any of the volumes. Subsequently, the volumes are upgraded to
include the material present in the supplement

In order to maximize the use of a standard, the major finalized (core) parts
should be published expeditiously. Subsequently, after sufficient time, the
items that had need to be discussed and brought to a consensus can be
published in the form of supplements. This would permit XSD1.1 to be
published with only the most minimal of changes. Subsequently a supplement
that include an extended date schema could be published. 

Parenthetically, one approach to the coding of the date data-types and other
simpleTypes that are strings that represent a compound type, such as
Day-Month-Year, would involve the addition of a concatenation operator to
the pattern element.  This would permit compound types to be defined from
combinations of simpleTypes. The individual simpleTypes could be separately
validated and tested prior to their inclusion in the compound type.

A similar approach could be applied to the HTML5 standard, which could be
published prior to achieving consensus on the final form of the XML version
and items such, as the use of prefixes for RDFa. 

 

1)      Boehm, B. W., A spiral model of software development and
enhancement, Computer, 21, 61-72 (1988) 

Bob Leif

 

-----Original Message-----
From: Noah Mendelsohn [mailto:nrm@arcanedomain.com] 
Sent: Friday, December 02, 2011 9:39 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 11/21/2011 11:46 AM, Tantek Çelik wrote:

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

 

Right.

 

However, as Michael Sperberg-McQueen has pointed out, the XSD spec now
allows processors to support additional types.

 

I think I'm right that this also opens the possibility for W3C itself to
make much more granular Recommendations to introduce new types in the
future. Traditionally, XSD Recommendations have taken (all too many) years
to hatch, and introduction of new types has been tied to such big releases.

I see no technical barrier to the Schema WG or some other W3C group bringing
out a Recommendation that would define one or a few new types, and
presumably along with that some conformance terminology to distinguish
processors that support the type from those that don't.

 

Whether doing such incremental Recommendations meets the needs of those who
implement validators or the needs of users, I'm not sure, but I don't see a
logistical or technical barrier to producing such a Recommendation.

 

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

 

So, another path would be to start as you suggest, but rather than waiting
for a major XSD Release, consider putting out a recommendation just covering
the new type(s) when they're stable. Maybe or maybe not such a
Recommendation should come from the Schema WG as opposed to the HTML WG. In
general, I think the open design of the XSD 1.1 type system points the way
to a more decentralized development of type specifications; the Schema WG
may want to be involved in setting conformance requirements for widely
deployed schema validators (e.g. "an XSD 1.2 processor MUST support at least
type1, type2, etc.).

 

Noah