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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Inserting optional elements

[ Lists Home | Date Index | Thread Index ]
  • From: Robin LaFontaine <robin@monsell.co.uk>
  • To: Xml-Dev <xml-dev@lists.xml.org>
  • Date: Mon, 25 Sep 2000 11:45:12 +0100

I agree with James on this, it is always useful to have an identifier 
that is unique within the enclosing element. Note that NewsML for one 
has introduced a "Euid" (element unique id) for this purpose, though 
as it is not required it tends not to get used: and if it is not 
always present it may as well not be there!

I think the XML Schema key concept would support this, i.e. could be 
used to define such keys.

A concept important for data files, related to this, is the ability 
to say when the order is not significant, e.g. the list of element 
definitions in an XML Schema could come in any order, but would mean 
the same; and again, in Schema, the list of elements in a choice can 
be in any order. I do not think any of the schema languages support 
this, unfortunately.


At 6:18 pm +0200 22/9/00, james anderson wrote:
>"List-valued" entities are much easier to operate on if one required the
>elements to have identifying attributes. By "list-values" I mean any
>content where the element names are not sufficient to describe an
>unambiguous access path. We couldn't see any reason to support "blind"
>operations on an elements by position only. It doesn't even have to be a
>true id attribute - just among the siblings.
>Matthew Gertner wrote:
> >
> > Paul,
> >
> > This is an good point. XPath is not sufficient to specify the location of a
> > new element unambiguously. This is obvious from the following example:
> >
> > <element name="foo">
> >         <complexType>
> >                 <element ref="bar" maxOccurs="unbounded"/>
> >                 <element ref="baz"/>
> >                 <element ref="bar" maxOccurs="unbounded"/>
> >         </complexType>
> > </element>
> >
> > Suppose I have the following document:
> >
> > <foo>
> >         <bar/>
> >         <bar/>
> >         <baz/>
> >         <bar/>
> > </foo>
> >
> > If I want to add an element with the XPath "foo/bar[3]", then I have no way
> > of knowing whether this will result is bar,bar,bar,baz,bar or
> > bar,bar,baz,bar,bar. This is only one of several problems with XPath. We're
> > thinking about extending the standard to solve these problems, so I'd be
> > most interested to know if any other individuals, companies or 
> > are working on this and want to collaborate. I haven't checked whether the
> > W3C is working on this yet (but I will).
> >

-- -----------------------------------------------------------------
Robin La Fontaine, Monsell EDM Ltd
(Engineering data exchange and management using XML, R&D Project Management)
Tel: +44 1684 592 144 Fax: +44 1684 594 504
Email: robin@monsell.co.uk       http://www.monsell.co.uk


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

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