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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: YML: A Grand Unification of SAX and DOM? (fwd)

[ Lists Home | Date Index | Thread Index ]
  • From: "Rick Jelliffe" <ricko@allette.com.au>
  • To: <xml-dev@ic.ac.uk>
  • Date: Sat, 4 Dec 1999 18:07:16 +0800


 
From: Don Park <donpark@docuverse.com> 

 
> <element>
>  <pocket:attributes>
>    <att>
>      <ch>val</ch>
>    </att>
>  </pocket:attributes>
>  <pocket:children>
>    <foo>
>      <pocket:text>bar</pocket:text>
>    </foo>
>  </pocket:children>
></element>

Compare to XML less RSI-inducing
    <pocket ch="val"><foo>bar</foo></pocket>

Note that the XSL pattern to find the attribute ch of element
pocket is  "pocket/@ch"  for the XML but 
"element/pocket:children/../pocket:attributes/att/ch"
for the alleged SML. It could be said that one could use
"element/pocket:attributes/att/ch"  but then there is the
validation possibility where the pocket:attributes elements
are made part of some other element. 

Of course, it would be possible to make an implementation
of an XSL processor that interprets "pocket/@ch" as 
"element/pocket:children/../pocket:attributes/att/ch"
and hides this from the user.  It means that instead of looking
at a type field in the parse tree, the name is used (presumably
a better implementation method would be to translate
the alleged SML into standard XML DOM on import).

But then the user would have to have in mind the XML markup
when reading the alleged SML, which is an additional
mental burdon.  But I look forward to the development
of SPaths, SXSL, SDOM, SML Schemas, SPointers,
SLink, SInclusions, etcs.  At best, SML will make it easier
to get exactly where we are today anywhere.

><element>
>  <sax:cache>
>    <foo>bar</foo>
>  </sax:cache>
></element>

Compare to XML:
    <foo sax:cache="active">bar</foo>
When an effect follows element scope, it is better practise
to use elements than PIs. Otherwise
    <?sax cache="on"?><foo>bar</foo><?sax cache="off"?>
or perhaps
    <sax:cache><foo>bar</foo></sax:cache>

><element>
>  <sax:cache>true</sax:cache>
>  <foo>bar</foo>
>  <sax:cache>false</sax:cache>
></element>

Compare to XML:
    <foo sax:cache="active">bar</foo>
When an effect follows element scope, it is better practise
to use elements than PIs. Otherwise
    <?sax cache="true"?><foo>bar</foo><?sax cache="false"?>
but of course we cannot comment to deeply on a snapshot.

Rick Jelliffe

    


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

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

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