[
Lists Home |
Date Index |
Thread Index
]
- From: johns@syscore.com (John F. Schlesinger)
- To: "'Roger L. Costello'" <costello@mitre.org>
- Date: Mon, 02 Oct 2000 12:24:17 -0400
Dear Roger,
sorry to take so long to answer your note. You are indeed right for the
camera schema in your example as the elementFormDefault is "unqualified".
Henry Thompson explained it to me thus (in an email):
"'Qualified' and 'unqualified' are _not_ the same as 'prefixed' and
'unprefixed' (for elements). Your example document had _unprefixed_,
_qualified_ names for its elements (because it had a default namespace
declaration).
So your schema needs to have form='qualified', or
elementFormDefault='qualified', in order to schema-validate your instance."
What caused my confusion, of course, was that you were <import>ing the
namespaces and the approach I used was to <include> the namespaces. Here is
the camera.xml, the schemas are below and parse with Xerces 1.2.
------- Camera.xml (no prefixes at
all) ------------------------------------------
<?xml version="1.0"?>
<camera xmlns="http://www.camera.org"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation="http://www.camera.org Camera.xsd">
<body>
<description>Ergonomically designed casing for easy
handling</description>
</body>
<lens>
<zoom>300mm</zoom>
<f-stop>1.2</f-stop>
</lens>
<manual_adapter>
<speed>1/10,000 sec to 100 sec</speed>
</manual_adapter>
</camera>
----------------------------------------------------------------------------
------
A note to the brave: I started using XML Spy and XML Authority but found
that both come to grief on <import/>. Interestingly, XML Spy wouldn't even
let me use a targetNamespace without also declaring the namespace (surely a
bug?). So I moved to Xerces-1_2_0. This parsed the examples with the
command:
java sax.SAXCount -v camera.xml
(The documentation says that validation on is the default, but actually the
opposite is the case).
You may be interested in the timings on my P3 650MHz (I have no idea if this
is meaningful):
Camera.xml not exposing namespaces
Validate No Validation
DOM 750ms 350ms
SAX 900ms 200ms
Camera.xml exposing namespaces
Validate No Validation
DOM 920ms 340ms
SAX 1070ms 200ms
Camera.xml Including namespaces
Validate No Validation
DOM 330ms 750ms
SAX 880ms 191ms
-------- Camera.xsd (using
elementFormDefault="qualified") ----------------------
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="http://www.camera.org"
xmlns:camera="http://www.camera.org"
elementFormDefault="qualified"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation=
"http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema.xsd">
<include schemaLocation="Nikon.xsd"/>
<include schemaLocation="Olympus.xsd"/>
<include schemaLocation="Pentax.xsd"/>
<element name="camera">
<complexType>
<sequence>
<element name="body" type="camera:body" minOccurs="1"
maxOccurs="1"/>
<element name="lens" type="camera:lens" minOccurs="1"
maxOccurs="1"/>
<element name="manual_adapter" type="camera:manual_adapter"
minOccurs="1" maxOccurs="1"/>
</sequence>
</complexType>
</element>
</schema>
-------- Nikon.xsd (using
elementFormDefault="qualified") ------------------------
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="http://www.camera.org"
elementFormDefault="qualified"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation=
"http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema.xsd">
<complexType name="body">
<sequence>
<element name="description" type="string" minOccurs="1"
maxOccurs="1"/>
</sequence>
</complexType>
</schema>
-------- Olympus.xsd (using
elementFormDefault="qualified") ----------------------
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="http://www.camera.org"
elementFormDefault="qualified"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation=
"http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema.xsd">
<complexType name="lens">
<sequence>
<element name="zoom" type="string" minOccurs="1" maxOccurs="1"/>
<element name="f-stop" type="string" minOccurs="1"
maxOccurs="1"/>
</sequence>
</complexType>
</schema>
-------- Pentax.xsd (using
elementFormDefault="qualified") -----------------------
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/1999/XMLSchema"
targetNamespace="http://www.camera.org"
elementFormDefault="qualified"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation=
"http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema.xsd">
<complexType name="manual_adapter">
<sequence>
<element name="speed" type="string" minOccurs="1"
maxOccurs="1"/>
</sequence>
</complexType>
</schema>
Sorry to have been so longwinded!
Yours,
John F Schlesinger
SysCore Solutions
212 619 5200 x 219
917 886 5895 Mobile
-----Original Message-----
From: Roger L. Costello [mailto:costello@mitre.org]
Sent: Saturday, September 23, 2000 2:32 PM
To: John F. Schlesinger
Cc: xml-dev@lists.xml.org; Cokus,Michael S.; Pulvermacher,Mary K.;
Heller,Mark J.; JohnSc@crossgain.com; Ripley,Michael W.
Subject: Re: XML Schemas: Best Practices
I don't believe that this is correct John. Let's consider my new
(bug-free) version of Camera.xml:
(see http://www.xfront.com/BestPractices.html)
<?xml version="1.0"?>
<my:camera xmlns:my="http://www.camera.org"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation=
"http://www.camera.org
Camera.xsd">
<body>
<description>Ergonomically designed casing for
easy handling</description>
</body>
<lens>
<zoom>300mm</zoom>
<f-stop>1.2</f-stop>
</lens>
<manual_adapter>
<speed>1/10,000 sec to 100 sec</speed>
</manual_adapter>
</my:camera>
If I were to use a default namespace declaration, as you suggest:
<?xml version="1.0"?>
<camera xmlns="http://www.camera.org"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xsi:schemaLocation=
"http://www.camera.org
Camera.xsd">
<body>
<description>Ergonomically designed casing for
easy handling</description>
</body>
<lens>
<zoom>300mm</zoom>
<f-stop>1.2</f-stop>
</lens>
<manual_adapter>
<speed>1/10,000 sec to 100 sec</speed>
</manual_adapter>
</camera>
then my instance document is asserting that all the elements belong to
the namespace: http://www.camera.org. If you look at the schema you
will see that description, zoom, f-stop, and speed all belong to
different namespaces (the camera schema imports elements from three
different namespaces). Thus, a default namespace would not work in this
case. Agree? /Roger
"John F. Schlesinger" wrote:
>
> If you want to hide namespaces in the instance, you can do a little better
> than
> the example shown by using the targetNamespace in the <schema> as the
> default namespace
> in the instance.
>
> Roger's example becomes:
> <?xml version="1.0"?>
> <camera xmlns=http://www.camera.org … >
> <body>Ergonomically designed casing for easy handling</body>
> <lens>300mm zoom, 1.2 f-stop</lens>
> <manual_adaptor>1/10,000 sec to 100 sec</manual_adaptor>
> <camera>
>
> No a big change, but it eliminates the need even to prefix the document
root
> element.
>
> I found this useful for development teams that had understood XML but not
> namespaces and schemas.
> The idea was for the XML engineer to do the schema and for the development
> teams to produce valid
> instances or to validate other teams' instances using a schema validator.
>
> Note that there is a difference between prefixing elements and qualifying
> them (which is why this
> works) which is one of the reasons for constructing schemas so that the
> developers don't have to
> wrestle with the difference.
>
> If there are name collisions, namespaces have to be used.
>
> Yours,
> John
> 212 319 5327 Home
> 917 886 5895 Mobile
>
> -----Original Message-----
> From: Roger L. Costello [mailto:costello@mitre.org]
> Sent: Friday, September 22, 2000 10:45 AM
> To: xml-dev@lists.xml.org
> Cc: costello@mitre.org; Cokus,Michael S.; Pulvermacher,Mary K.;
> Heller,Mark J.; JohnSc@crossgain.com; Ripley,Michael W.
> Subject: Re: XML Schemas: Best Practices
>
> Hi Folks,
>
> I am delighted to see the responses to my last message. Clearly people
> are thinking about this issue and have strong feelings about hiding
> namespace complexities in the schema versus making namespaces explicit
> in instance documents. This is good! Now let's see if we can distill
> out some general guidelines on when to hide and when to make explicit.
>
> Based upon some of the responses I can see that I did not do a very
> satisfactory job in motivating when you would want to hide the namespace
> complexities. So let's quickly address that again, and then move on to
> guidelines for when it is desirable to make namespaces explicit in
> instance documents.
>
> Recall the camera example that was presented. By designing the schema
> so that body, lens, and manual_adaptor are children of camera (i.e.,
> local elements), and by setting elementFormDefault="unqualified" we
> enable the creation of a class of instance documents that are pretty
> straightforward to read and write. An example of one instance document
> was presented:
>
> <?xml version="1.0"?>
> <my:camera xmlns:my=http://www.camera.org … >
> <body>Ergonomically designed casing for easy handling</body>
> <lens>300mm zoom, 1.2 f-stop</lens>
> <manual_adaptor>1/10,000 sec to 100 sec</manual_adaptor>
> <my:camera>
> Recall that the schema imported the declaration of the body element from
> the nokia schema, the lens element from the olympus schema, and the
> manual_adaptor element from the pentex schema. Looking at the instance
> document above one would never realize this. Such complexities are
> localized to the schema. Thus, we say that the schema has been designed
> in such a fashion that its complexities are "hidden" from the instance
> document.
>
> Several people responded to this design approach arguing that they
> believe that it is good and perhaps necessary to qualify body, lens, and
> manual_adaptor. Below I show the instance document with all elements
> qualified with a namespace:
>
> <?xml version="1.0"?>
> <my:camera xmlns:my="http://www.camera.org"
> xmlns:nikon="http://www.nokia.com"
> xmlns:olympia="http://www.olympia.com"
> xmlns:pentex=http://www.pentex.com …>
> <nikon:body>Ergonomically designed casing for easy
> handling</nikon:body>
> <olympia:lens>300mm zoom, 1.2 f-stop</olympia:lens>
> <pentex:manual_adaptor>1/10,000 sec to
> 100 sec</pentex:manual_adaptor>
> <my:camera>
>
> This instance document makes explicit that the body element comes from
> the nikon namespace, the lens element comes from the olympia namespace,
> and the manual_adaptor element comes from the pentex namespace.
>
> Thus, we come to two fundamental questions:
>
> [1] When does it make sense to design a schema to hide the namespace
> complexities from instance documents?
>
> [2] When does it make sense to design a schema to force instance
> document to make explicit the namespaces of its elements?
>
> The later question will be answered in the next section. For now, let's
> try to characterize the systems for which it makes sense to hide the
> namespace complexities in the schema.
>
> As I compare the two versions of the instance documents above the first
> thing that strikes me is the difference in readability. The first
> version is much easier to read. The namespaces in the second version -
> both the namespace declarations and the qualifiers on each element - are
> very confusing to an average fellow like myself.
>
> So, I come to the first characteristic:
>
> "For systems where readability is of utmost importance design the schema
> to hide the namespace complexities."
>
> I can well imagine writing an application to process the camera instance
> document such that it (the application) does not care what namespace the
> body element comes from, what namespace the lens element comes from, or
> what namespace the manual_adaptor element comes from. Such complexities
> are irrelevant to the application. The application just cares that the
> camera element contains a body element with the proper type of data, a
> lens element with the proper type data, and a manual_adaptor element
> with the proper type data. Knowledge of the namespaces that the body,
> lens, manual_adaptor elements belong to provides no additional
> information to the application. At the very best, the namespaces are a
> distraction to the application. If at some point the application does
> find it necessary to know what namespace an element is associated with
> then it will simply look it up in the schema.
>
> This brings me to the second characteristic:
>
> "For systems where knowledge of the namespaces of the elements provide
> no additional information design the schema to hide the namespace
> complexities."
>
> Those are the two characteristics that I see. Do you see any further
> characterizing features?
>
> Before moving on to when it makes sense to make the namespaces explicit
> in instance documents, I would like to pause and address Richard
> Lanyon's concern. Richard's concern is (paraphrasing):
>
> "Okay Roger, let's suppose that it makes sense to localize the
> complexities to the schema. An author of an instance document will
> still have to read the schema, and understand it, to write the instance
> document. Correct? How have we hidden the complexities of the
> schema?"
>
> Let me see if I can address this concern satisfactorily:
>
> [1] An instance document is written once but processed by many systems
> (write once, read many). All those systems which process the document
> are shielded from the complexities of the schema.
>
> [2] In the not-too-distant future there will be tools that read schema
> and provide a template for the instance document author to fill in. The
> tool will understand the schema and shield the author from needing to
> understand the schema.
>
> I hope that answers your concern satisfactorily Richard. If anyone else
> has anything to add to this please join in.
>
> Now let's move on to characterizing those systems for which it makes
> sense to design a schema to force instance document to make explicit the
> namespaces of its elements.
>
> First recall the techniques a schema uses to force instance documents to
> expose the namespaces of its elements.
>
> [1] Use elementFormDefault="qualified" to Force the Use of Namespace
> Qualifiers
>
> Len Bullard sketched out a schema for a 3D rendering system. Let me
> refer to that as the "video-game" schema. Let's see how to design that
> schema so that it forces instance documents to use namespace qualifiers
> on its elements:
>
> <?xml version="1.0"?>
> <schema xmlns="http://www.w3.org/1999/XMLSchema"
> targetNamespace="http://www.video-game.org "
> elementFormDefault="qualified"
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> xsi:schemaLocation=
> "http://www.w3.org/1999/XMLSchema
> http://www.w3.org/1999/XMLSchema.xsd"
> xmlns:design-works="http://www.design-works.com"
> xmlns:disney="http://www.disney.com"
> xmlns:mci=http://www.mci.com>
> <import namespace= http://www.design-works.com
> schemaLocation= "DesignWorks.xsd"/>
> <import namespace= http://www.disney.com
> schemaLocation= "Disney.xsd"/>
> <import namespace= http://www.mci.com
> schemaLocation= "MCI.xsd"/>
> <element name="video-game">
> <complexType>
> <sequence>
> <element ref="design-works:geometry" minOccurs="1"
> maxOccurs="1"/>
> <element ref="design-works:lighting" minOccurs="1"
> maxOccurs="1"/>
> <element ref="disney:character" minOccurs="1"
> maxOccurs="1"/>
> <element ref="mci:voice" minOccurs="1"
> maxOccurs="1"/>
> </sequence>
> </complexType>
> </element>
> </schema>
>
> The most important part of this schema is that elementFormDefault=
> "qualified". That attribute forces instance documents to qualify all
> elements:
>
> <?xml version="1.0"?>
> <video-game xmlns="http://www.video-game.org"
> xmlns:design-works="http://www.design-works.com"
> xmlns:disney="http://www.disney.com"
> xmlns:mci="http://www.mci.com"
> xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> xsi:schemaLocation="http://www.video-game.org VideoGame.xsd">
> <design-works:geometry> 24m x 71m</design-works:geometry>
> <disney:lighting>Shadow in foreground, light in back</disney:lighting>
> <mci:voice>Digitized voice</mci:voice>
> <video-game>
>
> [2] Declare Elements Globally to Force the Use of Namespace Qualifiers
>
> Global elements must be qualified in instance documents regardless of
> whether elementFormDefault has the value of "qualified" or
> "unqualified". Thus, we could reorganize the above schema to make all
> the elements global. [Interestingly, for the video-game schema I don't
> see how to make geometry, lighting, and voice global. Any thoughts?]
>
> Now it is time to answer the question: what characterizes systems for
> which it makes sense to design the schema so that instance documents are
> forced to display the namespaces for each element?
>
> One quick answer is:
>
> "For systems where knowledge of the namespaces DOES provide additional
> information design the schema to force exposure of namespaces in
> instance documents."
>
> However, this leaves me a bit empty. When does "knowledge of the
> namespaces provide additional information"? That is the question which
> must be answered.
>
> Suppose that an application will process the geometry element
> differently if it's associated with design-works versus some other
> namespace. I could imagine for marketing purposes such preferential
> treatment may occur. When else? What are your thoughts on this?
>
> Clearly namespaces are great for dealing with name collisions. In the
> video-game example I don't have multiple elements with the same name.
> If I did, however, and they came from different namespaces then it is
> easy to imagine that we would want to design the schema to force
> instance documents to expose the namespaces so that applications could
> easily distinguish the elements.
>
> Let's try rephrasing the above characterization given this new
> information:
>
> "For systems where knowledge of the namespaces does provide additional
> information design the schema to force exposure of namespaces in
> instance documents. Knowledge of namespaces may enable applications
> with:
> - namespace-dependent processing, and
> - distinguishing between elements with the same name."
>
> Okay, that's enough for now. Your turn. What are your thoughts on any
> of this? What guidelines would you provide someone who asks you:
> "Should I design my schema to hide the namespace complexities, or should
> I design it to force instance documents to expose the namespaces of its
> elements?"
>
> /Roger
|
