XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] [ANNOUNCE] New MicroXML draft available

+1
----
Stephen D Green



On 14 July 2011 12:29, Pete Cordell <petexmldev@codalogic.com> wrote:
FWIW I think the only attribute prefixes allowed should be "xml:".

To cater for the case below I would be happy (delighted!) to see 'type' in the XML namespace, so the example becomes:

<cost xml:type="xsd:float">29.95</cost>

Personally, I think this is the way it should have been done in the first place.

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- From: "Stephen D Green" <stephengreenubl@gmail.com>
To: "John Cowan" <cowan@mercury.ccil.org>
Cc: "Peter Flynn" <peter@silmaril.ie>; <xml-dev@lists.xml.org>
Sent: Thursday, July 14, 2011 11:56 AM
Subject: Re: [xml-dev] [ANNOUNCE] New MicroXML draft available



Looking back to the seminal blog/spec ('blec'?!) from James Clark
and the comments below it, it looks from your comment there John
that the main benefit from adding general prefixed attributes (not
just xml:*) to MicroXML is to be able to use xsi:type

<cost xsi:type="xsd:float">29.95</cost>


So, I wonder whether the cost of doing this in terms of necessary
namespace support (given we are trying to avoid that with MicroXML)
can be kept in proportion to the benefit by just allowing that one prefix
along with the xml: prefix as special cases in MicroXML. I'm not sure
how to express it in RelaxNG notation but I'd imagine adding xsi: to
the James Clark formal definition of MicroXML
( at http://blog.jclark.com/2010/12/more-on-microxml.html )
Quote:
"...
# Attributes
attribute ::= attributeName s* '=' s* attributeValue
attributeValue ::= '"' ((attributeValueChar - '"') | charRef)* '"'
               | "'" ((attributeValueChar - "'") | charRef)* "'"
attributeValueChar ::= char - ('<'|'&')
attributeName ::= "xml:"? name
...
"


where he has
attributeName ::= "xml:"? name

we might want it extended to include "xsi:"

So perhaps this is what we need

attributeName ::= ("xml:" |"xsi:")? name


(Did I get the notation right?)

Cheers

Steve
----
Stephen D Green



On 14 July 2011 07:11, Stephen D Green <stephengreenubl@gmail.com> wrote:

But say I were to add to my tutorial on MicroXML this
feature of any prefix being allowed in attribute names
(at present it just allows the xml: prefix, as per James
Clark's revised MicroXML spec), this would mean
having to include a lengthy and complex treatment of
XML Namespaces to cater for the fact that, with this
attribute prefix feature, namespace declarations other
than just the simple 'xmlns="..."' will start appearing in
MicroXML documents. Just allowing the xml: attributes
was fine with me; I'm not 100% sure on allowing other
prefixes though. I understand their benefits but the
cost of including 'xmlns:foo="...bar..."' namespace
declarations makes me uncomfortable with them.

Cheers

Steve


----
Stephen D Green



On 13 July 2011 18:56, John Cowan <cowan@mercury.ccil.org> wrote:

Stephen D Green scripsit:

> What is required of a parser handling prefixed and namespaced
> attributes in MicroXML?

Nothing at all, except that attribute names may contain a colon, whereas
element names must not.

The MicroLark parser can provide an object from which element objects
are pulled, or can push element objects to a content handler, or can
construct a tree of element objects.  In any of these cases, one can
use the getNamespace method to search along the ancestor-or-self axis
for the nearest appropriate namespace declaration.  If you think this
is too slow, you can create a subclass of Element that overrides the
getNamespace method to memoize its results, and use an ElementFactory to
tell the parser to instantiate your class rather than Element itself.

(One of the irritating non-features of SAX is that it doesn't expose
the parser's element stack, forcing the application to keep its own.
MicroLark push and pull parsing does expose the stack, though Ghu help
you if you mutate it in any way.)

--
De plichten van een docent zijn divers,         John Cowan
die van het gehoor ook.                         cowan@ccil.org
    --Edsger Dijkstra http://www.ccil.org/~cowan








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS