W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

RE: Semantics [was: Re: Well-formed (was: Re: F2F Proposed Resolutions Draft Updates)]

From: Mike Barta <mikba@microsoft.com>
Date: Mon, 20 Jun 2005 11:31:01 -0700
Message-ID: <7DF35A0B5F67E84B9095C21C8A97641805232F92@RED-MSG-33.redmond.corp.microsoft.com>
To: <w3c-wai-gl@w3.org>

Might we move 'well formed' into guide doc as part of the discussion of
sufficiency and state only that SGML derived documents be unambiguously
parsable.  

Leave to guide or techniques the 'test' of well formedness and have the
SC state what we intend:  that the parse tree is available
unambiguously. 

/m

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Roberto Scano (IWA/HWG)
Sent: Monday, June 20, 2005 5:19 AM
To: christophe.strobbe@esat.kuleuven.be; w3c-wai-gl@w3.org
Subject: Re: Semantics [was: Re: Well-formed (was: Re: F2F Proposed
Resolutions Draft Updates)]


This means that xhtml pages served as text/html for IE (and
application/xhtml+xml for others), for IE are inside first case
(SGML-based formats).
Also "HTML Techniques" need also to be HTML/XHTML (or "Markup
Techniques"), due that inside there are also example of "correct use" of
<applet> and <embed> elements? And, also, there is suggested to use
target attribute for open new windows instead of script: but "target"
is not allowed in XHTML 1.0 Strict (and also in HTML 4.01 Strict)...

----- Messaggio originale -----
    Da: "Christophe Strobbe"<christophe.strobbe@esat.kuleuven.be>
    Inviato: 20/06/05 13.14.30
    A: "WAI-GL"<w3c-wai-gl@w3.org>
    Oggetto: Re: Semantics [was: Re: Well-formed (was: Re: F2F Proposed
Resolutions  Draft Updates)]
      
    Hi Joe,
    
    At 19:16 17/06/2005, Joe Clark wrote:
    
    >>It is true that SGML does not define well-formedness, but if you
say that 
    >>a well-formed document is essentially "one that can unambiguously
be 
    >>parsed to create a logical tree in memory" (Jon Bosak, at 
    >>http://www.isgmlug.org/n3-1/n3-1-18.htm), then you can apply this
concept 
    >>also to SGML.
    >
    >OK, so let me understand this: The Working Group is contemplating
issuing 
    >a vague and counterfactual guideline based on one person's blog
posting,
    
    The new success criterion is not based on Jon Bosak's article; if
you had 
    that impression, that is entirely my fault (i.e. the wording of my
response 
    to Gez Lemon). I tried to identify criteria for well-formedness
"after the 
    fact".
    
    We now have 2 SCs at GL 4.1 L 1: one for SGML-based formats and one
for all 
    other formats. We may consider splitting the first one into two SCs:
one 
    that requires well-formedness for XML-based formats and one that
requires 
    something else for non-XML SGML-based formats, but we're still
struggling 
    to define this "something else". If we want to stick to the terms of
the 
    SGML standard, we could require that "Non-XML SGML-based delivery
units are 
    formatted according to the SGML declaration of their specification
or to 
    the Reference Concrete Syntax if no SGML declaration is defined." We
might 
    then add a note saying that this does not require (type-)validity.
The XML 
    specification does not define well-formedness by means of an SGML 
    declaration but in Extended Backus Naur Form; this is why I propose
to 
    split the first rule instead of treating XML as a special case of
SGML.
    An SGML declaration defines such things as the character set and the

    characters that can be used for delimiters (e.g. <, >, </); it
defines a 
    "concrete syntax". The Reference Concrete Syntax is a concrete
syntax 
    defined in the SGML standard.
    (Note that SGML parsers are not required to detect or report
errors.)
    
    Regards,
    
    Christophe Strobbe
    
    
    
    -- 
    Christophe Strobbe
    K.U.Leuven - Departement of Electrical Engineering - Research Group
on 
    Document Architectures
    Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
    tel: +32 16 32 85 51
    http://www.docarch.be/ 
    
    
    
        

[Messaggio troncato. Toccare Modifica->Segna per il download per
recuperare la restante parte.]
Received on Monday, 20 June 2005 18:31:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:37 UTC