Re: [xml-dev] [ANNOUNCE] New MicroXML draft available

["Pete Cordell" <petexmldev@codalogic.com>]

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
>>>
>>
>>
>