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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Structured attributes

[ Lists Home | Date Index | Thread Index ]
  • From: Al Gilman <asgilman@iamdigex.net>
  • To: ht@cogsci.ed.ac.uk (Henry S. Thompson), "XML Developers' list" <xml-dev@xml.org>
  • Date: Thu, 02 Mar 2000 21:06:20 -0500

The requirement is dead on.  For orienting the vision-impaired user, we
really need to know which descendants of a node are parts of the object and
which are descriptors of the whole object.  

The main reason for not doing this with funny names is that there are less
disruptive ways to do it.  In the HTML review cycle, I suggested that we
extend the kind of idref that appears in html:label.for to endemic metadata
elements.  This is essentially what you are chewing on.  <title for=IDREF>
with for= defaulting to self.parent.

In the schema for a domain, one can make it clear at the outset if element
type foo is always a qualifier of its immediate parent element.  This
subclass of elements need not be lexically separable from other elements.  

For example, consider the 'title' element in SVG.  This is clearly a case
in point. Likewise the 'metadata'  element in an 'svg' element.  For i18n
reasons lots of other usages are being defined which are syntactic
subelements and semantically property assertions.  

Likewise, the significance or insignificance of order need not be done
based on syntax but by classing the container, which can be done either for
an instance or for an element type.  Consider writing an information model
for smil:par vs. smil:switch.

We should stick to defining the semantics in a competent model-writing
language and then bind that semantics to XML syntax by a straightforward
injection of the names from the domain into an XML grammar.

A grammar is incapable of expressing the fact that the rows and columns in
a table are both special cases of a common class of one-dimensional
container structures.  And this knowledge is essential to understanding the
semantics of tables, of solid spaces, etc.

XML is great as a tree-to-stream binding.  Let's not try to make it do
everything syntactically.  There are just too many applications that rely
on structures which are topologically of higher dimension than trees.  Well
formed XML gets you back to a faithful tree replica.  To understand the
full import of the resulting tree, consult the appropriate domain model.

Al

At 10:40 PM 2000-03-02 +0000, Henry S. Thompson wrote:
>[A moment's thought will lead to realisation that this is displacement 
>activity on the part of the XML Schema: Structures editor, who
>certainly has better things to do, but I need to get this off my
>chest.]
>
>Why not structured attributes in XML?  _Why_ structured attributes?
>Well, we all know the comparison between elements and attributes as
>they stand:
>
>Elements      Attributes
>ordered       unordered
>non-unique    unique
>structured    unstructured
>
>There are a lot of contexts in which the first two properties of
>attributes are desireable, but the third is a serious constraint.
>
>Here's a design sketch for adding structured attributes:
>
>  1) Reserve a family of hitherto unusable names as the names of
>  structured attributes: On balnace I favour names with an initial
>  full-stop (.), but there are arguments in favour of using an initial
>  colon (:) instead;
>
>  2) Use element syntax, at the beginning of all element content, with 
>     the following restrictions:
>     2a) No attributes on structured attributes;
>     2b) Contents is either all structured attributes or all text;
>     2c) Order doesn't matter;
>     2d) Uniqueness of names among sibling structured _and_, for children of
>         elements, vanilla old-style attributes.
>

>Example:
>
>  <person age='49'>
>   <.name>
>    <.first>Henry</.first>
>    <.last>Thompson</.last>
>    <.middle>Swift</.middle>
>  </.name>
>  <children otherParent='p33'>
>   . . .
>  </children>
> </person>
>
>The constraints above are equivalent to allowing 'attribute' children
>to the 'attribute' element in XML Schema, along with making the
>attribute name uniqueness constraint cumulative:
>
> <element name='person'>
>  <complexType>
>   <attribute name='age' type='integer'/>
>   <attribute name='name'>
>     <attribute name='first'/>
>     <attribute name='middle/>
>     <attribute name='last/>
>   </attribute>
>   <element name='children'>...</children>
>  </complexType>
> </element>
>
>Back to my day job :-)
>
>ht
>-- 
>  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
>          W3C Fellow 1999--2001, part-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
>		     URL: http://www.ltg.ed.ac.uk/~ht/
> 


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

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

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