Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Could EXI & PSVI benefit from some nicer text serialization? Re
 Liam brought up EXI.
It would be possible not treat it just like XML, HTML, JSON etc: make it an explicit non-goal to provide the same features it provides. I don't see that EXI has any explicit mention of parallel processing in the spec, so I presume that it was not the selling point: I expect the scenario is data streams where you can hopefully parse one one block beforevthe next arrives, which precludes coarse-grain parellelism at least. On the other hand, it could be taken as a positive use-case: what would be a XML-ish SMGL-family markup language that could directly express what EXI found necessary for efficient interchange? For example, if I read it right, EXI uses PSVI (i.e. typed DOM or schema info) information to get compression. So if the schema says an element is an xs:gDateTime, that value can be packed. It uses the base datatypes as storage types. Now, obviously, if you serialize this EXI out to XML with no schema you can add an @xsd:type on the element tag. But, no: that is really just a schema reference: if you use xs:type and provide a simple XSD data type, you are also saying declaring that the the element is simple: no attributes. (Am I wrong? This could have been superseded by some change, or I might be forgetting something.) But what if this EXI element whose data content is gDate has an attribute with base type boolean? Can we serialize it out to XML retaining that type metadata using any "standard" form, without getting confusing markup? Wouldn't we be better off with something like this?: <anniversary coming-up=true XXX:typed=true>2022-07-22</anniversary> where the lack of delimiters on the attribute value causes the name token to be recognized as data-typed, therefore boolean true, and XXX:typed attribute cause the content to be parsed as a datatype, so that the lexical signature \d+-.* gets it recognized as a gDate (etc.) Which is to say, couldn't the current lack of an external standalone as-XML-ish-as-possible form for the PSVI and EXI documents show a gap that plausibly need filling? Or is this where documents must be shoehorned into JSON? With Schematron, a super popular feature had turned out out to be SVRL: that validating the document was not the termination point of XML tools, but just another stage like any other transformation. Now I am not saying, necessarily that we must support everything in EXI (and certainly not the full PSVI) or be limited by it. (Presumably, it might support only all the storage datatypes that can be unambiguously lexically distinguished: but you could have some lexical convention to allow more, like 1990 is a number but 1990-00-00 is a gYear or whatever.) But maybe the bizarre boundary they impose is an opportunity in our technology for a markup language with less gap? Cheers Rick 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
