[ 
https://issues.apache.org/jira/browse/TINKERPOP-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431179#comment-17431179
 ] 

ASF GitHub Bot commented on TINKERPOP-848:
------------------------------------------

krlawrence edited a comment on pull request #1485:
URL: https://github.com/apache/tinkerpop/pull/1485#issuecomment-947604873


   I think part of the challenge here is the GraphML spec. There is solid 
normative guidance for the allowed schema but there seems to be very little in 
the way of normative guidance regarding the processing model. The Primer itself 
is not normative and does not cover all possible cases where the schema allows 
a `<default>` value. The ambiguity comes from a document such as this one:
   ```
   <graphml xmlns='http://graphml.graphdrawing.org/xmlns'>
     <key id='code'    for='node' attr.name='code'    
attr.type='string'><default>LHR</default></key>
     <key id='city'    for='node' attr.name='city'    
attr.type='string'><default>London></default></key>
     <graph id='routes' edgedefault='directed'>
       <node id='0' label='n1'>
         <data key='city'/>
       </node>
     </graph>
    </graphml>  
   ```
   When `n1` is created should it have both properties for `code` and `city` 
created using the default values? The spec provides no guidance (that I can 
find). I tested using Gephi which is a popular tool for working with various 
graph file formats. The results from Gephi yield a node with both properties. 
In the absence of normative guidance from the GraphML spec itself I would 
propose we be consistent with Gephi if we add support for default values to 
help with interchange between other tools, like Gephi, and TinkerPop. Given 
that a document can override the global default locally should it need to, to 
really generate a node with an empty string, that would seem to allow for all 
cases.
   ```
   <graphml xmlns='http://graphml.graphdrawing.org/xmlns'>
     <key id='code'    for='node' attr.name='code'    
attr.type='string'><default>LHR</default></key>
     <key id='city'    for='node' attr.name='city'    
attr.type='string'><default>London></default></key>
     <graph id='routes' edgedefault='directed'>
       <node id='0' label='n1'>
         <data key='city'> <default></default></data>
       </node>
     </graph>
    </graphml>    
   ``` 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support default attribute values in GraphMLReader
> -------------------------------------------------
>
>                 Key: TINKERPOP-848
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-848
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: io
>    Affects Versions: 3.0.2-incubating
>            Reporter: Pavel Klinov
>            Priority: Trivial
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Looking at the code of GraphMLReader I see that it doesn't support default 
> values of attributes, which are allowed by the GraphML spec. This is a bit 
> annoying especially if the input defines default values for attributes which 
> are used for mandatory data, e.g. edge labels. 
> One small example is the sample graph at [1]. "d_e" is the label attribute 
> with a default value. There're <edge .. /> elements w/o body later in the 
> document and reading those will throw a "java.lang.IllegalArgumentException: 
> Label can not be null" exception (if the vendor considers edge labels 
> mandatory).
> I'd personaly squash both keyIdMap and keyTypesMap into a single String -> 
> AttrInfo map, where AttrInfo would contain information about the data 
> attribute name, type, and the default value.
> [1] http://www.eecs.wsu.edu/~yyao/DirectedStudyI/Datasets/AS/sample.graphml



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to