[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Data streams and schema use and identification

• To: "'Dan Vint'" <dvint@m...>, "'xml-dev@l...'" <xml-dev@l...>
• Subject: RE: Data streams and schema use and identification
• From: "Klotz, Leigh" <Leigh.Klotz@p...>
• Date: Thu, 24 Apr 2003 11:30:21 -0700

Dan Vint write:

>I'm not looking to make something up, I'm trying to find a standard way of 
>doing this. I could have lived with the idea that if you use W3C schemas 
>you need the xsi attributes, etc in the data stream. I wasn't given that 
>and all I'm left with is the possibility of something that looks just like 
>a well-formed XML stream - with no idea what to validate it with.

In XForms [1] we explicitly state that xsi:schemaLocation and friends are
ignored inside the instance document, and provide an attribute on the
<model> element to allow the author to specify a normative list of Schema
URI references that must be resolved to provide the Schema components for
assessment.  XForms further allows direct inclusion of the <xs:schema>
element inside the model.  <xs:schema> elements may appear outside the
<model> but in the enclosing document and be referred to fromn the
model@schema attribute as fragments, if the host language supports
fragments.

So, in the sense of the original question, for XForms there is an XML
document that states what Schema defines the document validity, but the two
are not the same document: we require the enclosing document to define
validity for the included or referenced "instance document."  The enclosing
document is the XForms document, which itself is further embedded in a host
document such as an XHTML or SVG document.  

We can do this because processors can be directed to ignore
xsi:schemaLocation at the request of the system invoking the processor, and
must do this because the instance data and the form itself come from
different places, and likely have different authors and different levels of
trust. 

Use case details: The back-end server that accepts the POST is the ultimate
arbiter of document validlty.  The form author is responsible for the user's
interaction with the back-end server, and must be able to instruct the user
agent to act in the combined best interests of the user and the server.
(I.e., it's no good for anybody to allow the user to submit a purchase order
with a bogus discount element in it.)  The situation is similar for the
initial instance data, which may come from a separate source than the form
that edits it.  One point that novice users of XForms and XML Schema often
miss is that there are multiple Schema files, one per namespace, so the
model@schema attribute is a space-separated list.

One point that novice users of XForms and XML Schema often miss is that
there are multiple Schema files, one per namespace, so the model@schema
attribute is a space-separated list.
XForms does not follow the xsi:schemaLocation pattern of alternating
namespace and URI references, because we require the XForms processor to
resolve all of the URI references, and thus the xs:schema@targetNamespace
attribute provides the namespace.  

[1] http://www.w3.org/TR/xforms

• Follow-Ups:
  • RE: Data streams and schema use and identification
    • From: Dan Vint <dvint@m...>

• Prev by Date: RE: Statistical vs "semantic web" approaches to makingsense of the Net
• Next by Date: RE: Data streams and schema use and identification
• Previous by thread: RE: Data streams and schema use and identification
• Next by thread: RE: Data streams and schema use and identification
• Index(es):
  • Date
  • Thread