Re: laxly schema valid?

On Thursday 10 January 2002 16:03, Frederick Hirsch wrote:
> Is it correct to say that "Laxly schema valid" means that if a validating
> XML parser is operating in "lax" mode

Henry's response, I've tweaked the text a bit in 1.102 .

--

Re: Fwd: laxly schema valid?
Date: 11 Jan 2002 10:21:54 +0000
From: ht@cogsci.ed.ac.uk (Henry S. Thompson)
 To: reagle@w3.org
Cc: henry@w3.org, w3t-arch@w3.org

Joseph Reagle <reagle@w3.org> writes:
> This is a good point but my intent was that I could say "generate laxly 
> schema valid" to mean that people can insert content in ANY elements even 
> if there's no schema available for that content.

Your intent is certainly fine.  A longer way of saying it would be
"generate instances which are schema-valid by exploiting the lax
wildcard in the content model".

Ah, now I look at the full context, and would suggest 

  Implementation MUST generate schema-valid [XML-schema] EncryptedData
  or EncryptedKey instances as specified by the subsequent schema
  declarations (note these may contain non-schema-validated elements
  because of the lax wildcards therein) and SHOULD . . .

Note however that as far as I can tell there actually _aren't_ any
wildcards in the EncryptedData or EncryptedKey type definitions in the
most recent draft [1] ???

ht

[1] 
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-EncryptedType
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
                     URL: http://www.ltg.ed.ac.uk/~ht/


-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 11 January 2002 11:04:28 UTC