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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] A bunch of components, but no mandated organization - reas

[ Lists Home | Date Index | Thread Index ]
  • To: "Nathan Young" <natyoung@cisco.com>, "Roger L. Costello" <costello@mitre.org>, "XML Developers List" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] A bunch of components, but no mandated organization - reasonable?
  • From: "Chiusano Joseph" <chiusano_joseph@bah.com>
  • Date: Wed, 12 Jan 2005 13:49:06 -0500
  • Thread-index: AcT41mfKro3RSc1XT/mXC0WuwLS5xAAAEIng
  • Thread-topic: [xml-dev] A bunch of components, but no mandated organization - reasonable?

> -----Original Message-----
> From: Nathan Young [mailto:natyoung@cisco.com] 
> Sent: Wednesday, January 12, 2005 1:38 PM
> To: Roger L. Costello; 'XML Developers List'
> Subject: Re: [xml-dev] A bunch of components, but no mandated 
> organization - reasonable?
> 
> Hi.
> 
> > Suppose that:
> >
> > 1. There exist a collection of "components", and each component is 
> > well-defined and understood.
> >
> > 2. There does NOT exist any rules which specify how the components 
> > should be assembled.
> 
> Either no relation exists between the information (and I 
> don't think this is what you mean) or there are some rules 
> relating the pieces of information and it boils down to 
> questions about how to represent and communicate the relationships:
> 
>   - the document structure could imply information about the 
> relationships of the
>     information
>   - a supplemental structured document could hold information 
> about relationships
>     (meta data)
>   - your systems and my systems could both implement the same 
> sets of rules about
>     relationships
> 
> In all three cases but especially in the third, some 
> out-of-band communication is often needed to establish a 
> working relationship where we agree on the meaning of 
> components and their relationships.

Na ah - how about inference engines, acting on the information that is
semantically marked-up using RDF or OWL?
 
> > Can information be transmitted in a world where the building blocks 
> > are understood, but no grammar exists?
> 
> I'm not sure that I see a case where building blocks exist 
> without a grammar.  You always need rules to assemble the 
> blocks, then rules to assemble the assemblies.  The smaller 
> you break the blocks up, the simpler the rules get, but you 
> still need to express something about the information. You 
> can mark it up or use a schema or tell me what it is over the 
> phone or whatever.

> > Is a grammar necessary for information transfer?
> 
> You certainly don't have to explicitly model every 
> relationship that your recipient may be interested in.  
> That's what queries (transforms) are often used for.
> 
> > Consider XML Schemas.  Suppose that:
> >
> > 1. An XML Schema declares a bunch of independent elements (i.e.,
> > components)
> > and each component is understood.  For example, here's a 
> Book component:
> >
> > <xsd:element name="Book">
> >     <xsd:complexType>
> >          <xsd:all>
> >             <xsd:element name="Title" type="xsd:string"/>
> >             <xsd:element name="Author" type="xsd:string"/>
> >             <xsd:element name="Date" type="xsd:date"/>
> >             <xsd:element name="ISBN" type="xsd:string"/>
> >             <xsd:element name="Publisher" type="xsd:string"/>
> >         </xsd:all>
> >     </xsd:complexType>
> > </xsd:element>
> >
> > Here's a BookCover component:
> >
> > <xsd:element name="BookCover">
> >     <xsd:complexType>
> >          <xsd:choice>
> >             <xsd:element
> > name="Hardcover"><xsd:complexType/></xsd:element>
> >             <xsd:element
> > name="Softcover"><xsd:complexType/></xsd:element>
> >         </xsd:choice>
> >     </xsd:complexType>
> > </xsd:element>
> >
> > Everyone understands the meaning of each component in the Schema.
> >
> > 2. But there is no declaration tying the components together, e.g., 
> > there is no overarching element declaration that relates the Book 
> > component with the BookCover component.
> >
> > If I create an XML instance document using the components 
> and send the 
> > instance document to you, will you be able to understand my data?
> 
> If you are saying that the only way to have an agreement 
> about this is to code it into the XSD then I'm not sure I 
> agree.  I do think you have demonstrated that it's possible 
> to model books and cover types in a way that makes it 
> unnaturally difficult to relate the two.

I think Roger is asking a much simpler question than that, which is can
the information be understood if there is no relation between the two.
If we are talking about machine-to-machine communication, I believe the
answer is yes - if, for instance, one uses xml:id's (which would not
involve an overarching element declaration, as Roger describes).

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World 
> -------->Nathan
> 
> 
> >
> > /Roger
> >
> >
> >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an 
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> 
> 
> 
> -- 
> 
> 
> .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
> _.:||:._.:||:.
> 
> Nathan Young
> A: ncy1717
> E: natyoung@cisco.com
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS