[
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 -->
and
url %MFString; #IMPLIED
are
url CDATA #IMPLIED
or
<xsd:simpleType name="MFString">
<xsd:annotation>
<xsd:appinfo />
<xsd:documentation
source="http://www.web3D.org/technicalinfo/specifications/vrml97/part1/field
sRef.html#SFString">MFString is an array of SFString
values.</xsd:documentation>
</xsd:annotation>
<xsd:list itemType="xsd:string" />
</xsd:simpleType>
<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
converging:
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.
len
From: Seairth Jacobs [mailto:seairth@seairth.com]
How about...
<ur l="me1.jpg"/>
<ul l="me2.jpg"/>
or some such...
|
