- From: Robert Leif <rleif@rleif.com>
- Date: Mon, 26 Sep 2011 16:38:05 -0700
- To: "'Norman Walsh'" <ndw@nwalsh.com>, <public-html-xml@w3.org>
- Message-ID: <01b101cc7ca5$570bf030$0523d090$@rleif.com>
Norm et al.
"Where HTML goes to great lengths to defined how an agent must recover from
markup errors, XML is unforgiving in the face of markup errors".
It does not appear that XSD1.1 has a data-type containing the string
"exception". I believe that we should suggest to the group that is
developing XSD1.1 that they create one and define it in such a way that it
is compatible with HTML5 (See below). In the case of HTML5 and the XML
vocabulary that is based upon XSD1.1, the goal should be harmonization.
"However, as all of the use cases appear to have plausible solutions today,
solutions that do not appear amenable to significant improvement, it appears
that there is little that can be done beyond documenting these
circumstances."
The first part of the sentence, "However, as all of the use cases appear to
have plausible solutions today" implies that all of the problems have been
solved. It is followed by a phrase that there are still: "solutions that do
not appear amenable to significant improvement".
Does the all need to be changed to some or what? Do you mean: However, these
solutions do not appear amenable to significant improvement. It appears that
there is little that can be done beyond documenting these circumstances.
"we use the term "DOM" (Document Object Model) throughout as a general term
for any of these possible representations." Abbreviations should be spelled
out.
"Resolution HTML5 doesn't have an extensibility story that admits the
possibility of content in arbitrary namespaces."
This is correct and is also the heart of the problem. A reasonable solution
is to leave HTML5 alone; and instead, to define XHTML5 to be extensible.
HTML5 then would be left to do general purpose including entertainment web
pages and XHTML5 would be reserved for interfacing with XML and high
integrity applications. Since the browser is a program, it is not written in
either HTML or XML. However, its capabilities should be able to be met by
the programming language used for its implementation. Obviously, every
effort should be made to maximize the harmonization of HTML5 and XHTML5 and
much of the code employed to parse and render the two languages can be
common.
"2.3 How can islands of HTML be embedded in XML?"
There are two types of HTML islands. 1) The HTML elements are used to
facilitate formatting by CSS and are essentially ignored by the XML. 2) The
HTML elements that need to use XML elements. The first problem can be fixed
on the XML side by the creation of a very simplified HTML schema, which
consists of mostly strings, and using openContent mode="interleave". I
believe that the second will be partially solved by the introduction of
prefixes or curies for RDF. The rest may be complex and require that the XML
parser discern the underlying data-type, which is subsequently translated
into the HTML equivalent.
"Resolution This aspect of XML parsing could be addressed by a more lenient
parser (such as XML5)."
An improved solution for exception handling certainly should be included in
XML5; however, it should be independent of XML5. There is a significant
problem with the security of networks. The combination of strong typing and
assertions for the HTML-XML part probably will help. However, any solution
that crashes the network is obviously unacceptable. It has been possible to
use strong typing with exceptions. In a confined universe, it is possible to
create code in the SPARK programming language that will not create a
run-time exception. Even with exceptions, the exception handler can do
something much more useful than crashing the system. I believe that if the
data on an aircraft were or are stored in XML, the result would be some form
of recovery.
A simple exception type based on HTML5 is shown below.
<annotation><documentation>
Exception_Type is based upon "The following are DOMException
codes. [DOMCORE]" from HTML5, A vocabulary and associated APIs for HTML
and XHTML, W3C Working Draft 05 April 2011
This Version:http://www.w3.org/TR/2011/WD-html5-20110405 Section 2.8.8
Exceptions.
</documentation></annotation>
<simpleType name="Exceptions_Type">
<restriction base="token">
<enumeration
value="Index_Size_Err"/>
<enumeration
value="Domstring_Size_Err"/>
<enumeration
value="Hierarchy_Request_Err"/>
<enumeration
value="Wrong_Document_Err"/>
<enumeration
value="Invalid_Character_Err"/>
<enumeration
value="No_Data_Allowed_Err"/>
<enumeration
value="No_Modification_Allowed_Err"/>
<enumeration
value="Not_Found_Err"/>
<enumeration
value="Not_Supported_Err"/>
<enumeration
value="Inuse_Attribute_Err"/>
<enumeration
value="Invalid_State_Err"/>
<enumeration
value="Syntax_Err"/>
<enumeration
value="Invalid_Modification_Err"/>
<enumeration
value="Namespace_Err"/>
<enumeration
value="Invalid_Access_Err"/>
<enumeration
value="Validation_Err"/>
<enumeration
value="Type_Mismatch_Err"/>
<enumeration
value="Security_Err"/>
<enumeration
value="Network_Err"/>
<enumeration
value="Abort_Err"/>
<enumeration
value="Url_Mismatch_Err"/>
<enumeration
value="Quota_Exceeded_Err "/>
<enumeration
value="Timeout_Err"/>
<enumeration
value="Data_Clone_Err"/>
</restriction>
</simpleType>
-----Original Message-----
From: public-html-xml-request@w3.org [mailto:public-html-xml-request@w3.org]
On Behalf Of Norman Walsh
Sent: Monday, September 26, 2011 7:46 AM
To: public-html-xml@w3.org
Subject: New editor's draft of the HTML/XML TF Report
Good morning,
A few minutes ago, I published a new editor's draft of the HTML/XML TF
report. My sole focus was to address the comments raised by the TAG on
01 Sep 2011 in an effort to produce a document that they will publish on our
behalf.
I believe the changes are within the spirit of TF consensus as I understand
it, but feel free to castigate your humble editor if he's
mistaken:
<http://www.w3.org/2010/html-xml/snapshot/>
http://www.w3.org/2010/html-xml/snapshot/
Be seeing you,
norm
--
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
<http://www.marklogic.com> www.marklogic.com
Received on Monday, 26 September 2011 23:39:14 UTC