[E-Lang] Concerning XML docs

[Tyler Close]

At 11:20 AM 9/18/01 -0400, Jonathan S. Shapiro wrote:
>[CapIDL related, out of context]
>
>The longest portion of my conversation with MarkM last night concerned the 
>commitment to XML. At one point, he was quite distressed about committing 
>to XML, I suspect because of issues in the content model semantics. I 
>would like to understand this issue better, and if somebody knows of a 
>*brief* summary I can read, I would be very appreciative. I refer to the 
>issues that have forced canonical XML to diverge, and to the content model 
>semantic gap between the "official" version and the Xpath version of the 
>content model.
>
>My opinion, in the absence of further information, is that the XML world 
>has no artistic aesthetic worth mentioning, and that there *are* semantic 
>problems in the spec, but that the cost of deviation exceeds the cost of 
>poor semantics in this area.
>
>We cannot -- and should not try to -- redirect the XML community as a 
>whole, and this means that we should be prepared to parse full XML 
>wherever XML is generated by (a) humans or (b) tools outside of our own 
>tool suite. Note that we do not need a validating parser for this, and 
>that non-validating parsers really aren't that complex.
>
>That said, I am all in favor of using a sensible, restricted subset of XML 
>for use by our own tools. The most reasonable subset is probably minml 
>with the follwing attributes (only)
>
>     id        so we can encode graphs
>     idref    so we can encode graphs

    xsi:type    so we can encode polymorphic types.

IMHO, the XML Schema specification is overly complex, so we might want to 
use a "type" attribute that is not bound to the XML Schema specification.

Instead of using namespace prefixes, as XML Schema does, I think it would 
be simpler to just put the whole namespace URL into the value of the "type" 
attribute, so:

<accessor type="http://schema.example.com/circle.schema#Circle">
     <radius>5</radius>
</accessor>

or

<accessor type="http://schema.example.com/rectangle.schema#Rectangle">
     <width>5</width>
     <height>10</height>
</accessor>

ASIDE:
My mind boggles at what goes on at W3C. I am baffled that they are even 
calling SVG an XML format. The whole thing is done by inventing custom text 
encodings and putting these inside XML attribute strings. The design 
totally defeats the whole point of having a standard encoding format like 
XML. This is an especially grave tragedy since having a vector graphics 
format that is easily generated with XSLT is an important piece of 
application infrastructure.

>
>Speaking for myself, I might also argue for:
>
>     class    so we can apply CSS to decently display the results.

The type attribute should fulfill this purpose.

>
>     A.href    (or something equivalent to href) so that we can express
>         *outbound* links in minml. The issue here is that the
>         content restrictions on element bodies (#PCDATA) are not
>         quite the same as the restrictions for attributes, with the result
>         that off-the-shelf translators may not be able to reliably
>         produce HTML <a> entities without use of attributes for this
>         purpose
>
>     A.name (or equivalent) for the same reasons as above.

I'd recommend putting the link information inside of an element. If the XML 
is going to be viewed as HTML then it's going to have to go through an XSLT 
transformation anyways. This XSLT code can put the target reference into an 
<A> element, or an xlink:href attribute, or whatever.

Something like:

<accessor>
     <target>http://www.erights.org/index.html</target>
</accessor>

So an XML representation of the E distribution properties might look like:

<EProperties>
     <version>0.8.10alpha1</version>
     <vendorName>ERights.org</vendorName>
     <vendor>
         <target>http://www.erights.org/index.html</target>
     </vendor>
</EProperties>

A separate <target> sub-element should be used to contain the URL, rather 
than just putting it directly into the accessor element (ie: 
<vendor>http://www.erights.org/index.html</vendor>) since we may want to 
extend the link with additional information other than just the target 
reference. With the target reference in its own sub-element, the link 
information can be easily augmented by adding new sub-elements. Just as an 
example, a link to a SOAP endpoint might be represented as:

<accessor type="http://schema.w3c.org/SOAP/link.schema#Link">
     <target>http://www.example.com/quote</target>
     <interface>http://schema.example.com/quote.schema</interface>
</accessor>

It would also make sense to use this link format instead of the IDREF 
attribute:

<accessor type="http://schema.w3c.org/idref.schema#IDREF">
     <target>#id_string</target>
</accessor>

If we went this route, then the only attributes would be "id" and "type": 
"id" to give an element an identity and "type" to specify the format of the 
element content when the element is of a polymorphic type.

Tyler

>
>Of these, I could contentedly yield on the A's, but the class attribute 
>might prove valuable for visualization so as to key presentation using CSS.
>
>
>Jonathan


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com