LISTSERV mailing list manager LISTSERV 16.5

Help for XML-L Archives


XML-L Archives

XML-L Archives


XML-L@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

XML-L Home

XML-L Home

XML-L  September 1999

XML-L September 1999

Subject:

Re: Distributed XML development model - a common vocab and better namespace required?

From:

"Trevor.ioz" <[log in to unmask]>

Reply-To:

Trevor.ioz

Date:

Tue, 7 Sep 1999 06:56:35 +1000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (133 lines)

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>
My "schema"
<contactInfo default="Address1" oneormore unique > <StreetAddress> <address1
type=text maxlength=30>
etc...
</address1> <state> </state> <postcode> </postcode> </StreetAddress>
</contactInfo>
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
regards
Trevor


----- 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
namespace required?


> 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
shared
> >> models using exactly the approach I argue in the essay is
> >counterproductive.
> >
> >Is not all using the same words for the same meaning part of
communicating
> >properly. CBL is an attempt to define a vocab for business data, this way
we
> >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
> >development?
>
> 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
parties
> agree to a vocaulary that is effectively limited.  Developing
industry-wide
> 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
the
> 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
the
> patience nor the interest (financial or otherwise) to teach this
relatively
> 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
> incomprehensible.
>
> 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
XML.
>  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
can
> >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.
Then
> >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
> http://www.simonstl.com
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2018
February 2017
August 2016
June 2016
March 2016
January 2016
July 2014
April 2014
January 2014
July 2013
February 2013
September 2012
August 2012
October 2011
August 2011
June 2011
January 2011
November 2010
October 2010
July 2010
June 2010
March 2010
February 2010
January 2010
November 2009
September 2009
August 2009
July 2009
May 2009
March 2009
December 2008
October 2008
August 2008
May 2008
March 2008
February 2008
January 2008
December 2007
October 2007
August 2007
June 2007
March 2007
January 2007
December 2006
September 2006
July 2006
June 2006
April 2006
February 2006
January 2006
November 2005
September 2005
August 2005
July 2005
June 2005
May 2005
March 2005
January 2005
October 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
December 1997
November 1997
October 1997

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager