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] Attributes: syntax hacks

[ Lists Home | Date Index | Thread Index ]

That works too.  The basic issue is having a space as 
content in a list member if the list is an attribute. 
One has to delimit the member and the delimiter can 
be something that requires an entity to get rid of 
the problem:

URL='"me.jpg""me 2.jpg"'

Your solution and any variation of the element declaration 
approach works.  It won't work for atts because 
spaces ARE delimiters and certain operating systems 
(say MS and MAC) enable spaces in certain kinds of 
content (say filenames).  Type declarations in 
a DTD or Schema won't fix this.  So

<!ENTITY % MFString	"CDATA">	<!-- Strings	-->


url     %MFString; #IMPLIED




<xsd:simpleType name="MFString">
 <xsd:appinfo /> 
sRef.html#SFString">MFString is an array of SFString
<xsd:list itemType="xsd:string" /> 

<xsd:attribute name="url" type="MFString" /> 

still leave one needing a delimiter and the only 
place to declare that is in the English description. 
An author faced with this is likely to blow it 
unless an editor is silently doing the work.

url='"me.jpg""me 2.jpg"'

This is ugly but it is a result of several definitions 

1. A task to map an object-oriented language to a data object 
language (VRML to XML) where the native types don't match 
(VRML fields can contain arrays of strings (MFString)).

2. The well-known lack of structure in an attribute beyond 
a space delimited list

3. Two operating systems that allow spaces as content.

4. Using an attribute where only an element can do the 
job without hackery, thus paying the price of XML verboseness 
to prevent ugly and error-prone syntax.  One does this 
because matching any type with a structure to an element 
definition causes the file to explode in size and only 
a few cases of the use of that type require delimiting.

XML is a good idea but there are warts that will emerge 
and one should understand and document them because there 
isn't a good solution for all cases.  As I said before, 
the mistake some make is to think that a schema automagically 
fixes it when really, it is just documentation for the 
application builder to be aware of.   In this particular 
case, it outed when someone was doing a translation without 
building in a some context checking rules.


From: Seairth Jacobs [mailto:seairth@seairth.com]

How about...

<ur l="me1.jpg"/>
<ul l="me2.jpg"/>

or some such...


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

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