My conclusion is that I will not be using any schema, instead I will be:-
using an empty XML string for data entry purposes,
with another version of this string with all the field attributes defined as
attributes of the elements.
ie. empty string <contactInfo> <StreetAddress> <address1> </address1>
<state> </state> <postcode> </postcode> </StreetAddress> </contactInfo>
<contactInfo default="Address1" oneormore unique > <StreetAddress> <address1
</address1> <state> </state> <postcode> </postcode> </StreetAddress>
Having an empty string where a "dom tree" can add values to and where the
editor can determine what constraints must be applied to those values is
solved this way.
I will not be using a DOM, my DOM will be a STL vector - an array of
pointers into the XML string to provide a tree structure where the string
bits that represents the elements and entities of the string are known by
their start and end positions. This way a well developed string class can
handle the insertions and modicications required in editing the XML string.
This is very different to the classically recommended approach to XML, but
is is doable with out much effort or complexity. This is why I have focused
in on this approach, any suggestions would be welcome.
I am anaylsizing the CBL (common business langiage) for the purpose of
building an overall "schema/namespace" from which I can quickly produce my
own empty string and attribute string.
This is being devided up into Fields, Field groups ie contact info as above,
and items which are groups of field groups. This will allow me to define my
"world" in terms of the things in it and what they do with each other.
comments most welcome
----- Original Message -----
From: Simon St.Laurent <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, September 06, 1999 11:22 PM
Subject: Re: Distributed XML development model - a common vocab and better
> At 10:38 AM 9/5/99 +1000, Trevor.ioz wrote:
> >From: Simon St.Laurent
> >> It's interesting, but it looks to be headed completely the opposite the
> >> direction I'm going. If I'm reading it right, it's about creating
> >> models using exactly the approach I argue in the essay is
> >Is not all using the same words for the same meaning part of
> >properly. CBL is an attempt to define a vocab for business data, this way
> >may all use the same words and assume their meaning. Going the extra and
> >providing schemas only helps others but does it really restrict XML
> I think you may have already accepted significant assumptions about
> 'communicating properly' that my essay questions. While some agreements
> about the conversation are needed to get started, the approach that
> requires the schema to be defined before the conversation begins is going
> too far - in my opinion.
> 'Using the same words and assuming their meaning' requires that all
> agree to a vocaulary that is effectively limited. Developing
> vocabularies seems to be a task of questionable value, given the varying
> perspectives of different participants in industry, not to mention their
> ability to participate (actively or even barely) in such initiatives.
> (XML's chameleon-like transformation capabilities also appear to reduce
> need for such initiatives.)
> Does reliance on the pre-agreed schema model 'restrict XML development'?
> In large part, I have to answer yes. Such projects tend to restrict the
> range of 'XML developers' to a smaller group of experts, having neither
> patience nor the interest (financial or otherwise) to teach this
> simple technology to a broader base. The push for these kinds of common
> vocabularies drives large customers and large vendors to create tools
> oriented to this model of development - leading to the classic computing
> situation where tools are either incredibly expensive or free but
> I'd like to see XML support both centralized and distributed models,
> without an underlying bias toward either. Tools should be available for
> both; neither approach should be exclusively promoted by those pushing
> At present, I think we're okay in the tools department (as far as XML
> tools have developed), and pretty weak in the promotion department. Too
> many people still seem to think that committees and experts are the right
> tools for vocabulary creation, though that is certainly changing.
> >I would suggest there is a strong requirement for a Namespace definition
> >other than just URI which indicate which namespace is being used. DTD's
> >go someway to this but overcomplicates matters.
> There is a strong need for the use of namespaces to be clarified,
> certainly. The recent explosion on the XML-dev list demonstrates
> continuing difficulties in that area.
> >What is really needed is some way of defining names and including a big
> >description of how they are to be used and what options etc there are.
> >there is a need to show what other names make up part of this Entity. XML
> >Schema over does it is some ways and is incomplete in other ways.
> Defining names is definitely useful to both the centralized and the
> distributed approach. How useful schemas will be to either approach
> depends on the tools that the committee (itself an example of the
> centralized approach) comes up with. Tools for creating 'loose' schemas
> that can be quickly identified, easily documented, and readily extended
> will make it much easier for adherents of the distributed approach to go
> about their work.
> Simon St.Laurent
> XML: A Primer (2nd Ed - September)
> Building XML Applications
> Inside XML DTDs: Scientific and Technical
> Sharing Bandwidth / Cookies