Re: Comma delimited lists in SVG

"Arnold, Curt" wrote:
> 
> The current XML Schema Datatypes working draft has support for list types,
> but only for space separated list.  Apparently, support for other or arbitrary
> delimiters was considered and was rejected (at least for version 1.0).

Yes. Specifically, I proposed comma separated delimiters be added, and I
proposed that arbitrary delimiters be declarable (such as ";" "|" whatever
).

Apparently it is wrong to want to store anything other than a simple value
in an attribute. 

Which then gives a problem of mixing up attribute-like content with
content-like content; or having to make up use-specific naming conventions
for attribute grouping, and so on. Basically, XML only has one tree. Its
not possible to have real structured attributes, though this has been
proposed by others in the past. Which is why people currently store
structured attributes (examples - xpath, urls, style, svgs "d") in
attributes. 

My understanding is that space-separated lists are only in there because of
SGML (for example NAMES).

>  There
> are several places in SVG where comma separated lists are used where
> space-separated lists would be usable.  The use of space-separated lists
> would increase the effectiveness of Schema validation of SVG documents
> and compatibility with anticipated support for other XML list types subsequent
> to finalization of XML Schema.

It doesn't help if you want to do more than vector lists, for example,
though. Its still not possible to say "this attribute is a list of three
lists of two numbers" and stuff like that. (If one wanted to actually
describe a 2x3 matrix as such).

> 
> Comma separated lists are used in the font-style, font-variant, font-weight,
> unicode-range and font-stretch attributes of the <font> element. 

Yes, and those use a syntax already a W3C Recommendation since 1996.

>  All the possible items
> have no embedded spaces so use of a space-separated list should be acceptible.

But not for font-family. 

> (Note, for the unicode-range attribute, urage is used as the pattern for subsequent
> entries, I believe this should be urange).

Yes.
> 
> The system-required attribute of the <switch> element is described as a comma
> separated list of an enumeration of values (none of which contain embedded spaces).
> The DTD fragment for the attribute shows it a NMTOKEN which would not accept
> a comma delimited list.  If a space separated list was specified, the NMTOKENS
> type could be used.

Right. Thats a valuable suggestion, though again this is a change from
existing SMIL syntax.

> The x, y, dx, dy, rotate and attribute of <tspan> take either comma or space delimited lists.
> 
> The rgb format of the color datatype contains a comma-separated list like "rgb(255,255,255).
> However, in this case the structure of the datatype could not effectively be constrained
> by Schema datatypes and compatibility with CSS is required.

Yes. It would be better to enhance Schema to be able to describe what
people do, though. 

I suppose I am biased. I met EBNF way before I met DTD syntax, so I was
horrified whrn I saw how weak and poorly expressive SGML DTD syntax was. (I
mean, in the HTML 2.0 DTD, seeing %url; and getting my hopes up, only to
find that this actually meant "a string".) Then XML tidied up some of it,
but did not really increase the expressibility. Then Schema increased the
expressibility a bit. Regexps help. But EBNF is still much more expressive.

I note that URI syntax is  defined in EBNF, and XML syntax is also defined
in EBNF, and SVGs path element d attribute in EBNF... It would have been
really really neat to have been able to say, in a schema, that a particular
attribute value (or indeed a particular content) had a particular EBNF.
Subclassing what XML did. Saying "this attribute uses the following
subclass of "string" (that overused CDATA) as follows ....


> With the exception of the color datatype, I'd suggest that the definition of all these attributes
> be changed to strictly space-separated lists.

We might have to look at doing that if that is all that XSchema gives us.
However, I live in hope that XSchema improves.

Received on Monday, 13 March 2000 19:27:02 UTC