OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespaces, W3C XML Schema (was Re: ANN: SAX FiltersforNamespaceProcessing)

On Tue, Jul 31, 2001 at 03:59:41PM -0400, David E. Cleary wrote:
> Don't take this as arguing people should use unqualified
> elements. I'm just arguing that Schema isn't to blame for this.
> There are two reasons why someone would do this:
> 1. They have a reason to.
> 2. They do not know what they are doing.

3. They are actively encouraged to write documents this way because that
   is the way it's taught in XML training courses and books.

4. They copied an example from the SOAP specification.

The reason Simon wrote his filter in the first place was in reaction to
something taught by a very respected XML trainer.  If I remember
correctly (and I'm sure there are several here who will help me out if
that isn't the case) conversation with Henry Thompson and others earlier
in the year yielded the interesting observation that those who teach W3C
XML Schemas teach use of either unqualified child elements or qualified
ones -- but neither camp teach a mix.  Clearly there's a "best practice"
issue at stake.

Your assertion that "[W3C XML] Schema isn't to blame" is wrong -- if the
new model of document processing brought about by W3C XML Schema didn't
exist, ie. the ability to imply the semantic relationship between the
child and parent elements, then there wouldn't be a confusion.
Personally speaking, I can't say I saw this pattern of XML usage much
before 'Schema.

I'm unsure why at this point anybody wants to take such a rigid
position w.r.t. W3C XML Schema.  They exist, are important whether we
like them or not, and the best thing to do is agree on unambiguous
practice to maximise document portability.

Seems to me that it would be better if all the respected trainers and
writers would land firmly on one side of this argument, rather than

-- Edd